New Bipolar Boost TX and Front End

[Mdtoday]

The simulation ran fine KingJL, nice work and thanks for sharing



cheers

Mdtoday

[KingJL]

... I am about to start loading 2 sets of boards, I'll need to order the inter-board connector and I'm stilling waiting on the inductors to be delivered and jig up a 20v supply, so hopefully I can start checking power supply stages in a day or so at least...

I plan on using these (I have 5 of them) for my 20V and 5V power supplies. I included inrush protection on the board to prevent a current higher than they will tolerate.

It will be at least a week before I start populating the boards, as I have family coming to visit next week. I am also going to do some major restructuring of the VHDL. The TX_Timing module is becoming too large and unwieldy to be able to easily comprehend the logic. I am going to break it up into 4 or five modules, namely TX_RX, TX_Timing, RX, Compensation_Feedback, and CIC_Comp_Filter. That will make the logic contained in all modules less complex and should make everything easier to comprehend.

A word of caution as you test. A slip of a probe off a pin of an SMD device can easily destroy your FPGA. I have over 50 yrs experience working with electronics circuitry and yet I recently destroyed a VMH3CS logic board and had to have it replaced. A probe slipped off a pin of a 16 pin SOIC analog switch and ended up taking out an FPGA output pin that resulted in shorting out the 3.3V supply.

[Mdtoday]

I plan on using these (I have 5 of them) for my 20V and 5V power supplies. I included inrush protection on the board to prevent a current higher than they will tolerate.

It will be at least a week before I start populating the boards, as I have family coming to visit next week. I am also going to do some major restructuring of the VHDL. The TX_Timing module is becoming too large and unwieldy to be able to easily comprehend the logic. I am going to break it up into 4 or five modules, namely TX_RX, TX_Timing, RX, Compensation_Feedback, and CIC_Comp_Filter. That will make the logic contained in all modules less complex and should make everything easier to comprehend.

A word of caution as you test. A slip of a probe off a pin of an SMD device can easily destroy your FPGA. I have over 50 yrs experience working with electronics circuitry and yet I recently destroyed a VMH3CS logic board and had to have it replaced. A probe slipped off a pin of a 16 pin SOIC analog switch and ended up taking out an FPGA output pin that resulted in shorting out the 3.3V supply.

I will be using this board I designed some time ago, its good from 4-36v @ 4A protected, I have quite a few of them built , so will make up a rig for testing using a couple of them.

The modular restructuring sounds good.

I've been in the electronics game for over 40 years, had my share of smoke n sparks and I'll heed your words of caution, hats off to you for your over 50 years JL, that's a lot of experience and it shows.

You should see a delivery very soon.

Cheers

Mdtoday

[KingJL]

... You should see a delivery very soon...

I guess so!!!!






A million "I thank you"s!'

Almost done with restructuring of the VHDL. Have everything working... VHDL much less cluttered. The output of the CIC filter actually starts to appear after ~8 ms. It really shows up when running the simulator with the restructured code which show when RX data is available from the RX module. Will be posting the update later this evening.

[Mdtoday]

I guess so!!!!


A million "I thank you"s!'

Almost done with restructuring of the VHDL. Have everything working... VHDL much less cluttered. The output of the CIC filter actually starts to appear after ~8 ms. It really shows up when running the simulator with the restructured code which show when RX data is available from the RX module. Will be posting the update later this evening.

Great to see they arrived ok and you are very welcome, thanks for sharing your project.

Excellent news on the VHDL, its sounding very promising.

Went to order the power mosfet STB8NM60T4 last night and realised the package type is the larger D2PAK.
I have ordered STB5NM60T4 which is the DPAK

Oh and I short changed you on the boards, I have an extra 2 sets here I pulled out of the pack to have a look at under the scope but they didn't make it back in the bundle lol, oops!

cheers

Mdtoday

[KingJL]

Major VHDL Restructure

I have radically restructured the VHDL code. It now consists of 3 (later to be 5) modules, TX_RX, TX_Timing, and RX. The top module TX_RX manages the communications register, calculates the clock counts for PRT, PW, TX_Boost, DAMP, RX_blanking, etc for the TX_timing module and CIC decimation rate for the RX CIC filter. It also receives the RX data from the RX module, posts it in the communications register, and notifies the host that new RX data is available. The restructured VHDL is much more organized and easier to read and comprehend (at least in my opinion).

The link to the new zip ( Vivado_Bipolar_TX(6-17-2019).zip ).

A sim run of the restructured VHDL:

You'll notice that the RX CIC filter starts showing the effects of input data at about 800 usec and keeps increasing until it reaches maximum value at about 20.5ms. The presence of output data is observed by the appearance of the "RX_DATA_RDY_o" signal. The value of the RX data for all three samples is in the last 3 entries of the "register_set" array.

[Mdtoday]

The restructured VHDL is much more organized and easier to read and comprehend (at least in my opinion).

You'll notice that the RX CIC filter starts showing the effects of input data at about 800 usec and keeps increasing until it reaches maximum value at about 20.5ms. The presence of output data is observed by the appearance of the "RX_DATA_RDY_o" signal. The value of the RX data for all three samples is in the last 3 entries of the "register_set" array.

Nicely done JL, very clean, great job and a lot of work, thanks for sharing.

The filtering looks really good.

Cheers

Mdtoday

[KingJL]

Updated Vivado Design Files

Well, all the company has gone back to their respective homes... so now back to the project!

First a recommendation/observation... R1 and R2 are the wrong value for safe operation of the inrush current limiter. Using R1 and R2 at the stated value (1 ohm) would result in a maximum input current of 2.5A... substantially above the 1.5A spec for the LM317. I would recommend that only R1 be utilized (leaving R2 position unpopulated)... this will still permit an input current of 1.25A. Using 1.5 ohm for R1 and R2 would result in an input current of 1.666A... slightly over the 1.5A spec.

I have added to the FPGA hardware definition. Added the S0 filter and added logic so that the S0 output can tune the damp start time. Also added a Finite State Machine (FSM) to control the events immediately after turn on or immediately after a timing change. Now the sequence is (1) calculate all event timings and filter decimation rates, (2) fine tune the damp start time, (3) determine the static coil decay value for samples 1,2, & 3, (4) determine the ground + coil decay for those same samples, (5) normal operation. The ground and coil decay samples will be used to normalize the S1, S2, and S3 samples so that we are essentially dealing with target strength at these sample times. Left to implement are the finishing target FIR filter and the (very) slow ground/mineralization filter. The slow ground/mineraliation filter will further modify the main S1 and S2 target data that is fed to the finishing FIR filter. The output of the FIR finishing filter will be passed (via the I/O register set) for use by the embedded processor. All of the intermediate stage target data is presented via the I/O register set so that future processing decisions can be made without changing the hardware definition.

I plan on using the Digilent rotary encoder pmod to facilitate user input to facilitate user input to change operating modes/parameters. I have also been researching the method to provide an audio output. I think I have decided to use the Vivado DDS ip feeding a PWM (or a pseudo PDM) to implement a 1 bit DAC. The DDS will be driven by the target value after reaching a predetermined threshold.

I am putting Ebay and MOUSER orders together to exercise after the 1rst of July for the parts that I do not already have. So I should be populating the PCB's in parallel with working on the hardware definition. Soon it will be time to bring the MicroBlaze embedded CPU into play.

The new Vivado_Bipolar_TX(6-27-2019).zip containing the Vivado project can be found here.

[Mdtoday]

Well, all the company has gone back to their respective homes... so now back to the project!

First a recommendation/observation... R1 and R2 are the wrong value for safe operation of the inrush current limiter.
...........
.......................
I am putting Ebay and MOUSER orders together to exercise after the 1rst of July for the parts that I do not already have. So I should be populating the PCB's in parallel with working on the hardware definition. Soon it will be time to bring the MicroBlaze embedded CPU into play.

.

Thanks for the info JL, I will make and test those changes in next day or so.
I have 99% of components now, just the interface connector to be received, I ended up purchasing a lot of passive components from LCSC this time around just to try them out. parts were here in 4 days. I added a few reels of commonly used values of R & C components I use. At prices of around $5-$8 per 4000 , for Yageo brand, I couldn't resist.

The sampling section described is looking really good, thanks for sharing, I will download and have a look at the latest files.
The proposed audio generation method is a nice slick way of implementing the sound output, I like it.
I think the embedded MicroBlaze CPU will have an easy time.

Again thanks for sharing your project, I'll post up some progress photos of PCB assembly soon.

Cheers

Mdtoday

[KingJL]

... I ended up purchasing a lot of passive components from LCSC this time around just to try them out...

Thanks for the tip... just checked them out... cut my Mouser order down to just 5 items (THAT1512, DG418B, OPA828,FDS4935BZ,FQS4901).

[KingJL]

Added AXI4 communications interface & defined an audio module

This weekend I added an interface to the AIX4 bus that will be needed when we package the TX-RX as a peripheral for use with the MicroBlaze embedded processor. The AIX4 bus interface is is thoroughly confusing and the Xilinx ip for using the interconnect provides little if any insight... Then I run across a blog article by Dan Gisselquist, Ph.D., Gisselquist Technology, LLC. So much easier to understand... and whats more he provides a module that interfaces the full AXI4 protocol to a simpler register based interface. Originally, I had designed the register based interface to have one channel for both read and write with separate enable signals. To interface with the AXI4 bus and the microblaze embedded processor requires separate channels for read and write, so I changed the register interface to provide that functionality. Also the AIX4 bus interface provides a reset signal that is low when active, so I changed all reset processing to work with a active low.

The latest Vivado_Bipolar_TX(7-1-2019).zip containing the project files can be found here.

I also defined an audio module for use with the project when we get to the stage where it is needed. The audio module consists of a numerically controlled oscillator (NCO) with a sine lookup table that passes a 10 bit sinusoidal signal to a pulse density modulation (PDM) encoder. I have designed the audio module to provide a sinusoidal tone that is between 190Hz and 3050Hz controlled by a frequency control word that is normally the value of the processed target signal. The frequency out (F) is F = CLK * FCW / (2**accumulator size (bits)). As designed the CLK = 100MHz and accumulator size = 29 bits. To keep the oscillator frequency within design limits, any time the input FCW is greater than 2^14 we subtract 2^12 ... any time the FCW is less than 2^10 we add 2^12. Sounds strange but it works. The DPM is clocked at 100 MHz also so the output can easily function as a 1 bit dac by filtering with a low pass RC filter with a cutoff of ~ 3000Hz.

The Vivado simulator waveforms for the audio module (FCW = 4096):

The Vivado project for the audio is in the ./Audio subdirectory (off of the Bipolar_TX directory) contained in the project zip.

[Mdtoday]

Nice work JL.
Yes, the AXI interface is a beast, I had to write some test code for an ECU some time back and it did my head in for a while.
I started off with Xilinx examples and found they had bugs, so still had to figure it out, which I eventually did but after reading the article you linked to, I wish I had that at the time, sure would have helped. Well written, thanks for the link.

The changes made to your code is looking very good, and the audio is going to be great, nice work.

Ill run the simulator tonight when I get home, been very busy with work.

The connectors should be delivered in a day or two so I'll be able to finish 2 sets of boards off.

Again, thanks for sharing.

Cheers

Mdtoday

[KingJL]

Hello MicroBalze

Well, it was about time to start to bring the embedded processor into the picture, sooo.... Getting microblaze up and running was fairly easy. So far I have created a configuration that includes the clock generator (that generates 2 clocks: 100MHz and 50MHz), the microblaze processor with 32 KByte block ram internal memory, external memory controller with another 512KBytes, reset controller, interrupt controller, AXI Bus Interconnect, a PIO block, QuadSpi controller (to have access to the on-board flash memory), usbuart (to be used during development and debug), and the Debug Module. Everything is up and running smoothly and I can program and interact with of the peripherals.

Bipolar_PI.pdf

It took countless hours to find out exactly how to access the flash storage. But in the end the answer was there all the time (although expertly hidden). I plan to use the last subsector (4 KB) of the flash to store the the PI Detector parameters that were in effect before the last shutdown. That way the user will not have to go through the initialization procedures every time the detector is turned on. The saved parameters will only take up 32 bytes. The reason to use the whole 4 KB subsector is that the memory area, that you are writing to, must be erased (an erase sets all bits to 1's) before writing. A write, or "program" command, only changes the "0" bits where appropriate... i.e. it can only change a "1" bit to a "0"... it cannot change a '"0" bit to a "1". The minimum granularity for an erase operation is 1 4 KB subsector... thus my decision to use the whole 4 KB subsector. I have a plan in mind how to efficiently use the 4 KB block an minimize the number of times that are needed to invoke the erase command as the erase command is very time consuming. For those that are interested, the CMOD-A7's flash is 32 megabits (4 MB) divided into 64 sectors of 64 KB each, which are further subdivided into 16 4KB subsectors which are further divided into 16 256byte pages. A fully defined VHDL program takes up about half (or about 32 sectors) leaving about 2 megabytes available for the software program.

I have started programming the initialization sequence. The plan is to move all of the initialization, with it's calculations of clock counts of all events, to the software side and remove them from the hardware VHDL side. Also, any decision logic will be moved to the software side, leaving the hardware TX-RX peripheral to the task of generating TX control signals and reading and filtering the RX. All post processing to determine ground balance adjustments to Samples 1 & 2, and comparisons of Samples 1 & 2 will be done in the software. After the software decisions are made and the target data appropriately adjusted, the software will "write" the result to the hardware (VHDL) audio peripheral.

In the next week, I will be bring into the Vivado block design, the TX-RX peripheral and the audio peripheral. The key to these 2 modules was the AXI bus interface solution that was discussed in my last post. After I bring in and integrate these last 2 modules, I will post the the whole updated Vivado project.

[waltr]

wow, sounds incredible.
Thanks for posting progress.

[Mdtoday]

Well, it was about time to start to bring the embedded processor into the picture, sooo.... Getting microblaze up and running was fairly easy. So far I have created a configuration that includes the clock generator (that generates 2 clocks: 100MHz and 50MHz), the microblaze processor with 32 KByte block ram internal memory, external memory controller with another 512KBytes, reset controller, interrupt controller, AXI Bus Interconnect, a PIO block, QuadSpi controller (to have access to the on-board flash memory), usbuart (to be used during development and debug), and the Debug Module. Everything is up and running smoothly and I can program and interact with of the peripherals.

[ATTACH=CONFIG]46816[/ATTACH]

It took countless hours to find out exactly how to access the flash storage. But in the end the answer was there all the time (although expertly hidden). I plan to use the last subsector (4 KB) of the flash to store the the PI Detector parameters that were in effect before the last shutdown. That way the user will not have to go through the initialization procedures every time the detector is turned on. The saved parameters will only take up 32 bytes. The reason to use the whole 4 KB subsector is that the memory area, that you are writing to, must be erased (an erase sets all bits to 1's) before writing. A write, or "program" command, only changes the "0" bits where appropriate... i.e. it can only change a "1" bit to a "0"... it cannot change a '"0" bit to a "1". The minimum granularity for an erase operation is 1 4 KB subsector... thus my decision to use the whole 4 KB subsector. I have a plan in mind how to efficiently use the 4 KB block an minimize the number of times that are needed to invoke the erase command as the erase command is very time consuming. For those that are interested, the CMOD-A7's flash is 32 megabits (4 MB) divided into 64 sectors of 64 KB each, which are further subdivided into 16 4KB subsectors which are further divided into 16 256byte pages. A fully defined VHDL program takes up about half (or about 32 sectors) leaving about 2 megabytes available for the software program.

I have started programming the initialization sequence. The plan is to move all of the initialization, with it's calculations of clock counts of all events, to the software side and remove them from the hardware VHDL side. Also, any decision logic will be moved to the software side, leaving the hardware TX-RX peripheral to the task of generating TX control signals and reading and filtering the RX. All post processing to determine ground balance adjustments to Samples 1 & 2, and comparisons of Samples 1 & 2 will be done in the software. After the software decisions are made and the target data appropriately adjusted, the software will "write" the result to the hardware (VHDL) audio peripheral.

In the next week, I will be bring into the Vivado block design, the TX-RX peripheral and the audio peripheral. The key to these 2 modules was the AXI bus interface solution that was discussed in my last post. After I bring in and integrate these last 2 modules, I will post the the whole updated Vivado project.

Great news, it's looking very good thanks for sharing.
On the hardware side, I have tested portions of the power supply circuits and rewound a set of pulse transformers, was hoping to do more than that over the weekend but didn't get the time.
As a matter of interest JL, which manufacturer of LM317 did you choose, I have the TI 1.5A version

Again, thanks for sharing.

Cheers

Mdtoday