Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi John, jt_eaton <84408@embeddedrelated> wrote: [] >>Now comes the overhead of connection between the two devices and I came >>up with a very stupid idea: what if my SoC bus (possibly a wishbone) >>gets extended to the other FPGA as well? > > If you do a full bus the number of signals will be a problem so you will > want to trim them down. You may also want to combine the read and write > datas in a single bidirectional bus to save pins. That is an option, but considering that we meet our pin budget with one device I guess there shouldn't be a problem with two of them. Routing though might be an issue, therefore I do take your suggestion as a valid one. > Do assign the slave fpga it's own memory space so that any time you move a > module then it's address will change. Otherwise you have to wait for a > slower out of chip response on every access. I'm afraid I haven't really understood this. Could you elaborate? FYI we have a 'memory manager' that essentially handles access to an EEPROM and an SRAM, as well as the internal RAM. The address space is flat from the 'users' point of view, but this will work only if the internal memory is on one device only, otherwise we will need to split the memory manager in two and that is not a good idea. > I have seen this done using fpgas with SERDES to serialize a amba ahb. Oh, I see, so essentially you have a bridge to translate the system bus transactions into packets of some sort. This approach is certainly interesting but it demands a bridge to be implemented, while in my approach there shouldn't be any additional cost (unless pin reduction is needed) to move slaves/masters around the two devices. AlArticle: 156851
On Tuesday, July 8, 2014 4:59:01 PM UTC-4, Gabor wrote: > > Any plan to support Verilog or mixed language projects? Version 0.06 has been released to CPAN with Verilog and Mixed HDL (VHDL + Verilog) support.Article: 156852
On Tuesday, July 8, 2014 4:36:34 PM UTC-5, Stef wrote: > I wouldn't dare looking up the price of a cypress 512kB FIFO after what I saw on their website earlier today. ;-) Don't overlook the cost of the power supply regulators to run the FPGA. It may still be good deal, but maybe just not quite as good... AndyArticle: 156853
In comp.arch.fpga, jonesandy@comcast.net <jonesandy@comcast.net> wrote: > On Tuesday, July 8, 2014 4:36:34 PM UTC-5, Stef wrote: >> I wouldn't dare looking up the price of a cypress 512kB FIFO after what I saw on their website earlier today. ;-) > > Don't overlook the cost of the power supply regulators to run the FPGA. > > It may still be good deal, but maybe just not quite as good... Good point. I had a quick look and it doesn't seem too bad. I already need a 3.3V and a 1.2V for the CPU so only an additional 2.5V if I need to use LVDS_25. Just need to allow for the extra current draw. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Pick another fortune cookie.Article: 156854
On 08/07/2014 15:43, Stef wrote: > To interface a fast sampling ADC to a CPU I'm considering to use a fifo > or dual ported ram and a small controlling CPLD. Cypress has a nice > offering of fifos and dp-rams, but looking at the prices of 512kb > density parts I got a bit of a shock: $75 for the fifo and $45 for the > dp-ram. That's in single quantity, but they don't go down fast either: > $30/1000+ for the dp-ram. :-( > (prices from cypress website) > > For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+ > $14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD' > for free. OK you still need a config memory. > (prices from avnet website) Just a thought but I use the CPU and it's memory to store the config information. It's not difficult to program a JTAG interface if you have a few spare I/O pins to eliminate config memory. > Can you just connect one side of the block ram to IO pins and read that > from a CPU as if it where a dp-ram? Other side interface would even be > simpler as you can keep it internal. > > Am I missing something here or is it really that simple? > (And yes, I do realize I have to program the FPGA to perform the > required function ;-) ) > > Sample rate is not extremely high (10MSPS), but too fast for the CPU to > read on interrupts directly. There may be other options, still > investigating. I'm left wondering if you want a Dual Port RAM, or a FIFO. They are different beasts but the FIFO would probably be best suited to an FPGA as it uses less pins and the data predictable. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 156855
In comp.arch.fpga, Mike Perkins <spam@spam.com> wrote: > On 08/07/2014 15:43, Stef wrote: >> To interface a fast sampling ADC to a CPU I'm considering to use a fifo >> or dual ported ram and a small controlling CPLD. Cypress has a nice >> offering of fifos and dp-rams, but looking at the prices of 512kb >> density parts I got a bit of a shock: $75 for the fifo and $45 for the >> dp-ram. That's in single quantity, but they don't go down fast either: >> $30/1000+ for the dp-ram. :-( >> (prices from cypress website) >> >> For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+ >> $14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD' >> for free. OK you still need a config memory. >> (prices from avnet website) > > Just a thought but I use the CPU and it's memory to store the config > information. It's not difficult to program a JTAG interface if you have > a few spare I/O pins to eliminate config memory. That is indeed an option I'm considering. It also has the advantage you only have 'one' piece of firmware to update in case of a field update. >> Can you just connect one side of the block ram to IO pins and read that >> from a CPU as if it where a dp-ram? Other side interface would even be >> simpler as you can keep it internal. >> >> Am I missing something here or is it really that simple? >> (And yes, I do realize I have to program the FPGA to perform the >> required function ;-) ) >> >> Sample rate is not extremely high (10MSPS), but too fast for the CPU to >> read on interrupts directly. There may be other options, still >> investigating. > > I'm left wondering if you want a Dual Port RAM, or a FIFO. > > They are different beasts but the FIFO would probably be best suited to > an FPGA as it uses less pins and the data predictable. Yes they are different, but what actually I need is a buffer. And that can be solved in many ways, including DPRAM and FIFO, they just need different logic and code around them. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Now I understand the meaning of "THE MOD SQUAD"!Article: 156856
> >I'm afraid I haven't really understood this. Could you elaborate? > When your master fpga accesses memory it needs to know if it is on the same chip as the master or on the slave chip. On chip is faster than having to send the address out to the slave and wait for a response. You should create a memory space for the slave chip and all of it's memory will reside in that address space. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156857
Hi John, jt_eaton <84408@embeddedrelated> wrote: [] >>I'm afraid I haven't really understood this. Could you elaborate? > > When your master fpga accesses memory it needs to know if it is on the same > chip as the master or on the slave chip. On chip is faster than having to > send the address out to the slave and wait for a response. You should > create a memory space for the slave chip and all of it's memory will reside > in that address space. Ok, now I understand your point. It is a valid one but it presumes two memory controllers, one for each device and then it becomes difficult to share an external memory since you'd need an arbiter to get access to it and no matter how smart you are, the arbiter cannot only sit on one of the FPGAs. It is true though that after the arbiter has granted the access (no matter what is the scheduling algorithm used), it certainly adds little overhead to the memory access compared to the additional delays you would face with an external memory on each read/write operation. That said the idea of having two memory controllers for the two FPGAs is against the very first idea to have the possibility to squeeze everything into one at a certain point without needing to rewrite the architecture. You are right though that any memory needed on the other device will certainly imply a decreased bandwidth.Article: 156858
Now, when you are at it, ask yourself the next question: "Do I really need = discrete CPU? Will not soft core within FPGA do the job just as well?". Low pin count MCUs with all memories on-chip are often a good idea, but it = sounds like your "CPU" is old style monster with parallel external bus. In = 2014 using such things is rarely optimal. The main justification for "CPU" I can think of is when "CPU" gives you on-= chip peripherals that can't be implemented in FPGA, like [moderate-speed] A= DCs or DACs or Ethernet Phy. But even then, I'd consider using MCU without parallel bus. In such configu= ration MCU governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control= plane" processing while FPGA is responsibly for all "data plane" processin= g, so high-speed 10 MSPs stream does not need to travel from FPGA to CPU. Another possibility is using quad-spi flash interface that is present on ma= ny of modern MCUs for passing ADC data from FPGA. But to my taste that's to= o kludgy.Article: 156859
In comp.arch.fpga, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > Now, when you are at it, ask yourself the next question: "Do I really need discrete CPU? Will not soft core within FPGA do the job just as well?". > Low pin count MCUs with all memories on-chip are often a good idea, but it sounds like your "CPU" is old style monster with parallel external bus. In 2014 using such things is rarely optimal. Well it's a 400MHz Cortex A9 with full double precision FPU unit and lots of internal SRAM. Test have shown that this CPU can handle the required algorithm. We also tested a 1GHz Cortex A8 with a 'light' FPU and external SDRAM, this one could not handle the required math. Is this something you can see an FPGA handle with reasonable developement effort and product cost? > > The main justification for "CPU" I can think of is when "CPU" gives you on-chip peripherals that can't be implemented in FPGA, like [moderate-speed] ADCs or DACs or Ethernet Phy. > But even then, I'd consider using MCU without parallel bus. In such configuration MCU governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control plane" processing while FPGA is responsibly for all "data plane" processing, so high-speed 10 MSPs stream does not need to travel from FPGA to CPU. > > Another possibility is using quad-spi flash interface that is present on many of modern MCUs for passing ADC data from FPGA. But to my taste that's too kludgy. Just today we where checking if an option would be to use no FPGA and connect the ADC through SPI. Proved the normal SPI port was too slow. But then we indeed had a thought about the quad-spi interface. On this CPU it uses a higher clock than the normal SPI and it can handle 1, 2 or 4 bits per clock. But then you would need to convert from ADC SPI to QSPI and have a buffer. So that means we're back to the buffer problem, just with another interface. ;-) -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) If built in great numbers, motels will be used for nothing but illegal purposes. -- J. Edgar HooverArticle: 156860
On 11/07/2014 09:26, already5chosen@yahoo.com wrote: > Now, when you are at it, ask yourself the next question: "Do I really > need discrete CPU? Will not soft core within FPGA do the job just as > well?". Low pin count MCUs with all memories on-chip are often a good > idea, but it sounds like your "CPU" is old style monster with > parallel external bus. In 2014 using such things is rarely optimal. > > The main justification for "CPU" I can think of is when "CPU" gives > you on-chip peripherals that can't be implemented in FPGA, like > [moderate-speed] ADCs or DACs or Ethernet Phy. But even then, I'd > consider using MCU without parallel bus. In such configuration MCU > governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control > plane" processing while FPGA is responsibly for all "data plane" > processing, so high-speed 10 MSPs stream does not need to travel from > FPGA to CPU. > > Another possibility is using quad-spi flash interface that is present > on many of modern MCUs for passing ADC data from FPGA. But to my > taste that's too kludgy. There is a lot we don't know. We don't know the ADC, it's interface or the speed it must run at. Pins are very expensive, and I do use SPI interfaces wherever possible to reduce pin count so I can use the cheaper, smaller packages for both FPGA and CPUs. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 156861
On Fri, 11 Jul 2014 15:27:49 +0200 Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: > In comp.arch.fpga, > already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > > Now, when you are at it, ask yourself the next question: "Do I really need discrete CPU? Will not soft core within FPGA do the job just as well?". > > Low pin count MCUs with all memories on-chip are often a good idea, but it sounds like your "CPU" is old style monster with parallel external bus. In 2014 using such things is rarely optimal. > > Well it's a 400MHz Cortex A9 with full double precision FPU unit and lots > of internal SRAM. Test have shown that this CPU can handle the required > algorithm. We also tested a 1GHz Cortex A8 with a 'light' FPU and external > SDRAM, this one could not handle the required math. > > Is this something you can see an FPGA handle with reasonable developement > effort and product cost? > Sure. Both X and A have SoC FPGAs now that incorporate Cortex A9s on the die. But is it worth the trouble of switching CPUs? Probably not. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 156862
Den onsdag den 9. juli 2014 22.15.04 UTC+2 skrev Stef: > In comp.arch.fpga, > > jonesandy@comcast.net <jonesandy@comcast.net> wrote: > > > On Tuesday, July 8, 2014 4:36:34 PM UTC-5, Stef wrote: > > >> I wouldn't dare looking up the price of a cypress 512kB FIFO after what I saw on their website earlier today. ;-) > > > > > > Don't overlook the cost of the power supply regulators to run the FPGA. > > > > > > It may still be good deal, but maybe just not quite as good... > > > > Good point. I had a quick look and it doesn't seem too bad. I already > > need a 3.3V and a 1.2V for the CPU so only an additional 2.5V if I need > > to use LVDS_25. Just need to allow for the extra current draw. > AFAIU you don't need to use 2.5V for LVDS_25 it'll work the same powered by 3.3V, there might be a difference in on chip termination. same for CMOS25@3.3V/CMOS33@2.5V the drive levels will just be slightly higher/lower than configured -LasseArticle: 156863
In comp.arch.fpga, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: > On Fri, 11 Jul 2014 15:27:49 +0200 > Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: > >> In comp.arch.fpga, >> already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: >> > Now, when you are at it, ask yourself the next question: "Do I really need discrete CPU? Will not soft core within FPGA do the job just as well?". >> > Low pin count MCUs with all memories on-chip are often a good idea, but it sounds like your "CPU" is old style monster with parallel external bus. In 2014 using such things is rarely optimal. >> >> Well it's a 400MHz Cortex A9 with full double precision FPU unit and lots >> of internal SRAM. Test have shown that this CPU can handle the required >> algorithm. We also tested a 1GHz Cortex A8 with a 'light' FPU and external >> SDRAM, this one could not handle the required math. >> >> Is this something you can see an FPGA handle with reasonable developement >> effort and product cost? >> > > Sure. Both X and A have SoC FPGAs now that incorporate Cortex A9s on > the die. But is it worth the trouble of switching CPUs? Probably > not. Had a quick look at the Z-7010 (X) and that has dual A9 core, each with VFPv3-D16 FPU (the fast one) and running at 667MHz or more. This is more than adequate for our needs. But it requires external DDR to get enough memory. Price is not too bad either, $55 at Digikey, comparable to the CPU + FPGA solution. But this thing looks like a huge and complex beast. How hard/easy is it to live with and design for? What I like about the Renesas RZ (that's the 400MHz A9) is its on die SRAM, so it requires only a QSPI FLASH to boot from and all else is internal. So no DDR busses and the like on the board. Only fast signal on the board is the ADC connection. Board still needs to be designed, so if we want to switch CPU, now is the time to do it. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) The most disagreeable thing that your worst enemy says to your face does not approach what your best friends say behind your back. -- Alfred De MussetArticle: 156864
In comp.arch.fpga, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: > > Had a quick look at the Z-7010 (X) and that has dual A9 core, each with > VFPv3-D16 FPU (the fast one) and running at 667MHz or more. This is > more than adequate for our needs. But it requires external DDR to get > enough memory. Price is not too bad either, $55 at Digikey, comparable > to the CPU + FPGA solution. > > But this thing looks like a huge and complex beast. How hard/easy is > it to live with and design for? Just found this: http://www.zedboard.org/product/microzed Tempting ... Could even uses it as plug in module while volumes are still low. When volumes climb high enough there will be a board re-design anyway. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) I couldn't remember when I had been so disappointed. Except perhaps the time I found out that M&Ms really DO melt in your hand. -- Peter OakleyArticle: 156865
On 12/07/14 00:33, Stef wrote: > In comp.arch.fpga, > Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: >> >> Had a quick look at the Z-7010 (X) and that has dual A9 core, each with >> VFPv3-D16 FPU (the fast one) and running at 667MHz or more. This is >> more than adequate for our needs. But it requires external DDR to get >> enough memory. Price is not too bad either, $55 at Digikey, comparable >> to the CPU + FPGA solution. >> >> But this thing looks like a huge and complex beast. How hard/easy is >> it to live with and design for? > > Just found this: http://www.zedboard.org/product/microzed > > Tempting ... Could even uses it as plug in module while volumes are still > low. When volumes climb high enough there will be a board re-design > anyway. Nice board /when/ it eventually turned up. Avnet's ordering system was, in my case, peculiarly awful. There does appear to be a reasonable "ecosystem" developing around variants and auxiliary boards, tools and tutorials. You also get a node-locked licence for some of the Xilinx toolset above and beyond their free Vivado/ISE WebPack. Or there is the "inverse equivalent"... http://www.zedboard.org/product/microzed-sbc MicroZed™ SBC (Single Board Computer) is based on the successful MicroZed SOM (System On Module), with the main difference being the flipped orientation of the I/O expansion connectors. With the I/O connectors on the topside of the board, the MicroZed SBC is designed to accept daughter cards for custom interfaces, making the SBC the main baseboard of a system. This is in contrast to the carrier card approach that is used with MicroZed SOM, where MicroZed plugs into the main baseboard or carrier card. The SBC approach, combined with the lower profile RJ45 Ethernet connector allows MicroZed SBC to serve as a very compact embedded processing system.Article: 156866
On Friday, July 11, 2014 4:27:49 PM UTC+3, Stef wrote: > In comp.arch.fpga, >=20 > already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: >=20 > > Now, when you are at it, ask yourself the next question: "Do I really n= eed discrete CPU? Will not soft core within FPGA do the job just as well?". >=20 > > Low pin count MCUs with all memories on-chip are often a good idea, but= it sounds like your "CPU" is old style monster with parallel external bus.= In 2014 using such things is rarely optimal. >=20 >=20 >=20 > Well it's a 400MHz Cortex A9 with full double precision FPU unit and lots >=20 > of internal SRAM. Test have shown that this CPU can handle the required >=20 > algorithm. We also tested a 1GHz Cortex A8 with a 'light' FPU and externa= l=20 > SDRAM, this one could not handle the required math.=20 >=20 >=20 > Is this something you can see an FPGA handle with reasonable developement= =20 > effort and product cost? >=20 You didn't tell us enough about your algorithm for me to answer. But I'd still try. In general, if an algorithm is of FIR filtering type, then the answer is al= most certainly "Yes and with relatively little effort". Even small modern F= PGA has a a lot more fix-point arithmetic power than 400 MHz Cortex A9. If = the algorithm is of IIR or FFT type then converting it to fix-point will ta= ke more understanding and more skilled developer, but still, it almost cert= ainly could be done. There are well-know methods of implementing IIR and FF= T in fix-point, like doing IIR by means of Lattice-Ladder scheme. The only sort of signal processing algorithms that can't be moved to FPGA i= s one that consists of very long chain of inevitably-dependent inevitably-f= loating-point operations. I personally never saw such algorithms used in si= gnal processing, but they could exist.Article: 156867
The key here is what latency you can withstand and what size you need. For = relatively small requires the internal SRAM of FPGAs like Spartan or Cyclon= e is fairly fast and cost effective solution. Fot bigger sizes and if you c= an accept a little more latency FPGA + SRAM/SDRAM/DDR3 is a good solution. = We get a lot of people using our Craignell2 -40/48 parts for this as we 256= Mb of SDRAM paired with a Spartan-3A. The 48 pin part allows a FIFO with 1= 6 bit data bus input and with up to 7 control signals and the mirror of tha= t on the output. The 40 pin can still do 16 bit data in/out but you can onl= y support 3 controls signals. To reduce latency a hybrid structure can be used for a FIFO. This is much m= ore complex but gives the bigger size without losing too much performance o= n latency. Basically to do this you have an input SRAM in the FPGA and on t= he way out an output SRAM. Those give the I/O speed. As appropriate blocks = of data are moved in/out of the SDRAM in a background operation. Filling(ou= tput) or emptying(input) SRAM elements of the FIFO.=20 One of the nice things you can do in this sort of FIFO that standard parts = can't usually do is differing interface sizes. So you might have an 8 bit w= rite with a 32 bit read. John Adair Enterpoint Ltd. =20 On Tuesday, 8 July 2014 15:43:32 UTC+1, Stef wrote: > To interface a fast sampling ADC to a CPU I'm considering to use a fifo >=20 > or dual ported ram and a small controlling CPLD. Cypress has a nice >=20 > offering of fifos and dp-rams, but looking at the prices of 512kb >=20 > density parts I got a bit of a shock: $75 for the fifo and $45 for the >=20 > dp-ram. That's in single quantity, but they don't go down fast either: >=20 > $30/1000+ for the dp-ram. :-( >=20 > (prices from cypress website) >=20 >=20 >=20 > For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+ >=20 > $14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD' >=20 > for free. OK you still need a config memory. >=20 > (prices from avnet website) >=20 >=20 >=20 > Can you just connect one side of the block ram to IO pins and read that >=20 > from a CPU as if it where a dp-ram? Other side interface would even be >=20 > simpler as you can keep it internal. >=20 >=20 >=20 > Am I missing something here or is it really that simple? >=20 > (And yes, I do realize I have to program the FPGA to perform the >=20 > required function ;-) ) >=20 >=20 >=20 > Sample rate is not extremely high (10MSPS), but too fast for the CPU to >=20 > read on interrupts directly. There may be other options, still >=20 > investigating. >=20 >=20 >=20 > --=20 >=20 > Stef (remove caps, dashes and .invalid from e-mail address to reply by= mail) >=20 >=20 >=20 > One man's constant is another man's variable. >=20 > -- A.J. PerlisArticle: 156868
Hi, I'm trying to implement a trigger with 2 BRAMs with one BRAM storing all th= e data samples from the ADC and another BRAM just transferring samples from= the 1st BRAM to the 2nd on the event of a trigger. I have an address gener= ator which is basically a counter and when the trigger occurs, it starts to= count up and lasts only for the duration of the number of samples. The add= ress is then stored in the register.=20 Now when the next trigger occurs, I'm trying to load back the stored regist= er address but I'm not certain what to use as the load signal for the count= er, since I'm using the trigger signal itself as the enable. Does anyone ha= ve any suggestions for the logic ? Thanks!Article: 156869
Syed Huq wrote: > Hi, > > I'm trying to implement a trigger with 2 BRAMs with one BRAM storing all the data samples from the ADC and another BRAM just transferring samples from the 1st BRAM to the 2nd on the event of a trigger. I have an address generator which is basically a counter and when the trigger occurs, it starts to count up and lasts only for the duration of the number of samples. The address is then stored in the register. > > Now when the next trigger occurs, I'm trying to load back the stored register address but I'm not certain what to use as the load signal for the counter, since I'm using the trigger signal itself as the enable. Does anyone have any suggestions for the logic ? > > Thanks! I'd suggest re-thinking the system. Copying data from one BRAM to another is an inefficient use of hardware. Why are you doing it? Is the idea just to have data from the two most recent triggers? If so, then why not just alternate capture between the two BRAM's and just keep track of which one was used last. -- GaborArticle: 156870
"Syed Huq" <syed.huq.a@gmail.com> wrote in message news:751fcc59-d1ac-4195-8b17-b5618dfb2f20@googlegroups.com... Hi, I'm trying to implement a trigger with 2 BRAMs with one BRAM storing all the data samples from the ADC and another BRAM just transferring samples from the 1st BRAM to the 2nd on the event of a trigger. I have an address generator which is basically a counter and when the trigger occurs, it starts to count up and lasts only for the duration of the number of samples. The address is then stored in the register. Now when the next trigger occurs, I'm trying to load back the stored register address but I'm not certain what to use as the load signal for the counter, since I'm using the trigger signal itself as the enable. Does anyone have any suggestions for the logic ? Thanks! Why not just swop the BRAM's over ping pong style on the next trigger? Or use one BRAM as a dual port with the address MSb on the Write port, and !MSb on the Read port, and use an XOR to invert the input MSb ( and consequently !MSb ) from trigger to trigger. AndyArticle: 156871
One BRAM is storing all the data samples from the ADC and since I also need= the pre-trigger data samples due to the delay, I'm then transferring over = the samples including some pre-trigger data to the second BRAM. The system = can have any number of triggers and I'm using the second BRAM to store all = the data from the triggers. I just need the data from the trigger events an= d not all the data being captured.=20 So my first BRAM is a simple dual-port RAM while my second BRAM is just a s= imple single-port RAM. My idea is that when the trigger event occurs, I cap= ture the address of the first BRAM at which the trigger occurs, set an offs= et for the pre-trigger data and use the second address bus to read data fro= m the first BRAM and start writing only the trigger data to the second BRAM= . There may be multiple triggers, but I'll be only storing the trigger data= in the second BRAM which is what I need.=20 On Monday, 14 July 2014 13:36:14 UTC-5, Gabor wrote: > Syed Huq wrote: >=20 > > Hi, >=20 > >=20 >=20 > > I'm trying to implement a trigger with 2 BRAMs with one BRAM storing al= l the data samples from the ADC and another BRAM just transferring samples = from the 1st BRAM to the 2nd on the event of a trigger. I have an address g= enerator which is basically a counter and when the trigger occurs, it start= s to count up and lasts only for the duration of the number of samples. The= address is then stored in the register.=20 >=20 > >=20 >=20 > > Now when the next trigger occurs, I'm trying to load back the stored re= gister address but I'm not certain what to use as the load signal for the c= ounter, since I'm using the trigger signal itself as the enable. Does anyon= e have any suggestions for the logic ? >=20 > >=20 >=20 > > Thanks! >=20 >=20 >=20 > I'd suggest re-thinking the system. Copying data from one BRAM to >=20 > another is an inefficient use of hardware. Why are you doing it? >=20 > Is the idea just to have data from the two most recent triggers? >=20 > If so, then why not just alternate capture between the two BRAM's >=20 > and just keep track of which one was used last. >=20 >=20 >=20 > --=20 >=20 > GaborArticle: 156872
Syed Huq <syed.huq.a@gmail.com> wrote: > I'm trying to implement a trigger with 2 BRAMs with one BRAM > storing all the data samples from the ADC and another BRAM just > transferring samples from the 1st BRAM to the 2nd on the event > of a trigger. I presume you want some about of data before and after the trigger. In that case, I would store data as a circular buffer, with the address wrapping when it go to the end. Then when a trigger comes in, count the appropriat number of additional cycles, still storing them in the same RAM. From the address at either the trigger or at the end, you can figure out where the samples are from before and after. If you have enough RAMs, or divide up the address space appropriately, you can use many such circular buffers. The only complication, and it will be easy to figure out with software at the end, is the case where two triggers come close enough together that it hasn't finished one before it needs to start the next. Just fix that up in software after you read the data out. Each circular buffer needs to be long enough to hold the samples before and after the trigger, no more. > I have an address generator which is basically a counter and > when the trigger occurs, it starts to count up and lasts only > for the duration of the number of samples. The address is then > stored in the register. -- glenArticle: 156873
On 7/14/2014 3:30 PM, Syed Huq wrote: > One BRAM is storing all the data samples from the ADC and since I also need the pre-trigger data samples due to the delay, I'm then transferring over the samples including some pre-trigger data to the second BRAM. The system can have any number of triggers and I'm using the second BRAM to store all the data from the triggers. I just need the data from the trigger events and not all the data being captured. > > So my first BRAM is a simple dual-port RAM while my second BRAM is just a simple single-port RAM. My idea is that when the trigger event occurs, I capture the address of the first BRAM at which the trigger occurs, set an offset for the pre-trigger data and use the second address bus to read data from the first BRAM and start writing only the trigger data to the second BRAM. There may be multiple triggers, but I'll be only storing the trigger data in the second BRAM which is what I need. > > On Monday, 14 July 2014 13:36:14 UTC-5, Gabor wrote: >> Syed Huq wrote: >> >>> Hi, >> >>> >> >>> I'm trying to implement a trigger with 2 BRAMs with one BRAM storing all the data samples from the ADC and another BRAM just transferring samples from the 1st BRAM to the 2nd on the event of a trigger. I have an address generator which is basically a counter and when the trigger occurs, it starts to count up and lasts only for the duration of the number of samples. The address is then stored in the register. >> >>> >> >>> Now when the next trigger occurs, I'm trying to load back the stored register address but I'm not certain what to use as the load signal for the counter, since I'm using the trigger signal itself as the enable. Does anyone have any suggestions for the logic ? >> >>> >> >>> Thanks! >> >> >> >> I'd suggest re-thinking the system. Copying data from one BRAM to >> >> another is an inefficient use of hardware. Why are you doing it? >> >> Is the idea just to have data from the two most recent triggers? >> >> If so, then why not just alternate capture between the two BRAM's >> >> and just keep track of which one was used last. >> -- >> >> Gabor I'm with Gabor. I think I understand what you are doing and I would say you can do it better without the second BRAM. You are using the entire first BRAM as a circular buffer to capture the data around the trigger. Then you copy just that data around the trigger to the second BRAM for multiple triggers, appending the data each time. This does not require two BRAMs. If you can't think of how to time the operations and generate the addresses, that shows it is a bit overly complex. I would logically divide one BRAM into multiple circular buffers. The first trigger just stores data in the small region allocated for it (the same size as the data you wish to see). The second capture uses the second region of the one BRAM and so on. The only complication of this method is that each trigger must save the starting address for the data in the corresponding circular buffer. That could be in the same buffer memory or in a separate buffer. The software that reads out the memory can unwrap the circular buffer as it reads out the data by knowing the starting address of the data and the bounds of the circular buffer. I honestly can't give you a suggestion about your original question because I don't understand what you are describing with the addresses and registers. You can certainly make the two BRAMs do what you want. If you want to do it that way, I just need to understand better what you are describing. You have a trigger circuit that is filling the first BRAM as a circular buffer. When armed it increments an address register continuously. On the trigger a length counter is started (I would use a down counter) that counts the number of samples to store following the trigger. When that counter expires the address register is loaded with the current address minus the size of the data you wish to transfer. The length counter is also reloaded with the number of samples you wish to transfer and transfers begin to the second BRAM. When the length counter expires a second time the transfers stop. At this point you can either rearm the trigger or stop everything and wait for a trigger arming signal. -- RickArticle: 156874
In comp.arch.fpga, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: > On 12/07/14 00:33, Stef wrote: >> In comp.arch.fpga, >> Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: >>> >>> Had a quick look at the Z-7010 (X) and that has dual A9 core, each with >>> VFPv3-D16 FPU (the fast one) and running at 667MHz or more. This is >>> more than adequate for our needs. But it requires external DDR to get >>> enough memory. Price is not too bad either, $55 at Digikey, comparable >>> to the CPU + FPGA solution. >>> >>> But this thing looks like a huge and complex beast. How hard/easy is >>> it to live with and design for? >> >> Just found this: http://www.zedboard.org/product/microzed >> >> Tempting ... Could even uses it as plug in module while volumes are still >> low. When volumes climb high enough there will be a board re-design >> anyway. > > Nice board /when/ it eventually turned up. Avnet's ordering > system was, in my case, peculiarly awful. Their site shows EU stock at the moment. If I'm going to order, I'll let purchasing handle the ordering system. ;-) > There does appear to be a reasonable "ecosystem" developing > around variants and auxiliary boards, tools and tutorials. > You also get a node-locked licence for some of the Xilinx toolset > above and beyond their free Vivado/ISE WebPack. There are a lot of examples for the Zed and microzed, looks ok indeed. Have not looked into those example however. > Or there is the "inverse equivalent"... > http://www.zedboard.org/product/microzed-sbc > MicroZed™ SBC (Single Board Computer) is based on the successful > MicroZed SOM (System On Module), with the main difference being > the flipped orientation of the I/O expansion connectors. With > the I/O connectors on the topside of the board, the MicroZed SBC > is designed to accept daughter cards for custom interfaces, > making the SBC the main baseboard of a system. This is in > contrast to the carrier card approach that is used with MicroZed > SOM, where MicroZed plugs into the main baseboard or carrier card. > The SBC approach, combined with the lower profile RJ45 Ethernet > connector allows MicroZed SBC to serve as a very compact embedded > processing system. Also nice, but for our product, out baseboard with the microzed plugged on looks like a possible solution. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Meade's Maxim: Always remember that you are absolutely unique, just like everyone else.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z