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
In comp.arch.fpga, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > On Friday, July 11, 2014 4:27:49 PM UTC+3, Stef 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? >> > > 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 almost certainly "Yes and with relatively little effort". Even small modern FPGA 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 take more understanding and more skilled developer, but still, it almost certainly could be done. There are well-know methods of implementing IIR and FFT 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 is one that consists of very long chain of inevitably-dependent inevitably-floating-point operations. I personally never saw such algorithms used in signal processing, but they could exist. The algorithm is a non-linear curve fitting algorithm and this will not be changed (now). I believe this algorithm fits your "inevitably-dependent inevitably-floating-point operations" case. ;-) There may be options for reducing the floating point needs or even convert to fixed point, but that involves time and risk. Which can be avoided if we use a platform that can handle the FP implementation. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Single tasking: Just Say No.Article: 156876
On 15/07/14 08:18, Stef wrote:
> In comp.arch.fpga,
> Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>> On 12/07/14 00:33, Stef wrote:
>> 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. ;-)
My experience...
- site showed two lines
- MicroZed 3 weeks wait
- JTAG cable in stock
- I ordered one of each line
- confirmatory email showed same information
- randomly checking by browsing the order next day showed
JTAG cable 4.5 *MONTHS* delay; both delayed until
both available
- /eventually/ managed to contact a human who nominally
cancelled the JTAG cable
- but cancellation did /not/ show on the order page
Unacceptable and unnecessary:
- that flip from "available" to 4.5 months after order
- without notice
- cancellation not indicated
>> 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.
The support forums are well attended by Avnet tech staff.
Several minor improvements have been made (now rev F), some
prompted by postings on the forums. Good response.
The support tutorial are helpful, but I've also found
third party tutorials helpful.
Article: 156877On Tuesday, July 15, 2014 10:29:57 AM UTC+3, Stef wrote: > In comp.arch.fpga, >=20 > already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: >=20 > > 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 reall= y need 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 b= us. 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 l= ots > >>=20 > >> of internal SRAM. Test have shown that this CPU can handle the require= d > >>=20 > >> algorithm. We also tested a 1GHz Cortex A8 with a 'light' FPU and exte= rnal=20 > >> SDRAM, this one could not handle the required math.=20 > >>=20 > >>=20 > >> Is this something you can see an FPGA handle with reasonable developem= ent=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 i= s almost certainly "Yes and with relatively little effort". Even small mode= rn FPGA 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 wil= l take more understanding and more skilled developer, but still, it almost = certainly could be done. There are well-know methods of implementing IIR an= d FFT in fix-point, like doing IIR by means of Lattice-Ladder scheme. >=20 > > The only sort of signal processing algorithms that can't be moved to FP= GA is one that consists of very long chain of inevitably-dependent inevitab= ly-floating-point operations. I personally never saw such algorithms used i= n signal processing, but they could exist. >=20 >=20 > The algorithm is a non-linear curve fitting algorithm and this will not b= e=20 > changed (now). I believe this algorithm fits your "inevitably-dependent= =20 > inevitably-floating-point operations" case. ;-)=20 > If low risk is highest priority then I can believe in "inevitably-floating-= point" part. But "inevitably-dependent" is harder to accept. Most non-linea= r curve fitting algorithm that I am aware of contain significant degree of = inherent parallelism (=3Dmultiple dependency chains). The most computationa= lly intensive parts of algorithms often consist of decomposition of symmetr= ic or hermitian matrices, which happens to have better numeric properties t= han decomposition of arbitrary matrices =3D can be done with lower precisio= n math. >=20 > There may be options for reducing the floating point needs or even conver= t=20 > to fixed point, but that involves time and risk.=20 Find the best numeric/algorithms person in the company and allow him to pla= y with your curve fit in Matlab for 2-3 days. That does not sound like a lo= t of time or risk to me and chances for big improvements w.r.t. to finding = more parallelizable and/or requiring lower precision method of computations= are very high. > Which can be avoided if=20 > we use a platform that can handle the FP implementation.=20 > --=20 >=20 > Stef (remove caps, dashes and .invalid from e-mail address to reply by= mail)=20 >=20 > Single tasking: Just Say No. Single tasking is VERY practical in embedded world in general, even more so= in system-on-programmable-chip province. Define hardware interfaces right = and you can eliminate most reasons for [preemptive] multitasking. Quite oft= en even interrupts not really needed. [O.T.] If low risk is highest priority then shouldn't you use Altera instead of Xi= linx?Article: 156878
In comp.arch.fpga, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: > On 15/07/14 08:18, Stef wrote: >> In comp.arch.fpga, >> Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >>> On 12/07/14 00:33, Stef wrote: >>> 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. ;-) > > My experience... > - site showed two lines > - MicroZed 3 weeks wait > - JTAG cable in stock > - I ordered one of each line > - confirmatory email showed same information > - randomly checking by browsing the order next day showed > JTAG cable 4.5 *MONTHS* delay; both delayed until > both available > - /eventually/ managed to contact a human who nominally > cancelled the JTAG cable > - but cancellation did /not/ show on the order page > > Unacceptable and unnecessary: > - that flip from "available" to 4.5 months after order > - without notice > - cancellation not indicated Unacceptable indeed. If we want to go in this direction, I'll talk to the FAE first and get his thoughts about availablity. Thanks for the warning. Is the JTAG cable required/recommendend? In a quick read I got the impression that you could just use a micro SD card. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) If the facts don't fit the theory, change the facts. -- Albert EinsteinArticle: 156879
On 15/07/14 09:31, Stef wrote: > In comp.arch.fpga, > Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >> On 15/07/14 08:18, Stef wrote: >>> In comp.arch.fpga, >>> Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >>>> On 12/07/14 00:33, Stef wrote: >>>> 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. ;-) >> >> My experience... >> - site showed two lines >> - MicroZed 3 weeks wait >> - JTAG cable in stock >> - I ordered one of each line >> - confirmatory email showed same information >> - randomly checking by browsing the order next day showed >> JTAG cable 4.5 *MONTHS* delay; both delayed until >> both available >> - /eventually/ managed to contact a human who nominally >> cancelled the JTAG cable >> - but cancellation did /not/ show on the order page >> >> Unacceptable and unnecessary: >> - that flip from "available" to 4.5 months after order >> - without notice >> - cancellation not indicated > > Unacceptable indeed. If we want to go in this direction, I'll > talk to the FAE first and get his thoughts about availablity. > Thanks for the warning. I should add: ordered 18th January, MicroZed shipped 1st April, i.e. 11 weeks, not 3. I suspect that if it is in stock in Europe, then the overall experience might be better. Ordering from the US is a pain w.r.t. payment of import duties. > Is the JTAG cable required/recommendend? In a quick read I got > the impression that you could just use a micro SD card. There are several ways of approaching programming and debugging the FPGA and ARM. The MicroZed tutorials give a good introduction. I found that third party tutorials helped (and slightly hindered) me when starting out with the (necessarily) complex Xilinx toolset. For me the SD card would be most useful after the FPGA hardware is stable. I don't know how many SD card insertions can occur before something is physically damaged. Buying 1 x JTAG HS2 Programming Cable (24624) = 51.86EUR from Trenz Electronics was painless. I also /suspect/ they have a reasonable long-term availability of their modules, at a price of course!Article: 156880
In comp.arch.fpga, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > On Tuesday, July 15, 2014 10:29:57 AM UTC+3, Stef wrote: <snip optimization> You are probably right that optimizations are possible and I expect that we will come to that when production numbers are expected to climb high enough. For now numbers are low and we will have to go with the current algorithm that was developed and proved over many years. Changing it would not only be a technical challenge but would also involve a lot of non-technical/political issues. This effort can not be justified in this phase of the project. >> >> Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) >> >> Single tasking: Just Say No. > > Single tasking is VERY practical in embedded world in general, even more so in system-on-programmable-chip province. Define hardware interfaces right and you can eliminate most reasons for [preemptive] multitasking. Quite often even interrupts not really needed. > Funny how those random signatures from 'fortune' often seem relevant to the post. ;-) > [O.T.] > If low risk is highest priority then shouldn't you use Altera instead of Xilinx? Could you explain this remark? I have used Xilinx in the past (Spartan 3E) and can not remember any issues. Also played with Altera at that time and did not realy find one better than the other, just different. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) ... [concerning quotation marks] even if we *___did* quote anybody in this business, it probably would be gibberish. -- Thom McLeodArticle: 156881
On Tuesday, July 15, 2014 11:56:05 AM UTC+3, Stef wrote: > > > > [O.T.] > > If low risk is highest priority then shouldn't you use Altera instead of Xilinx? > > > Could you explain this remark? > > I have used Xilinx in the past (Spartan 3E) and can not remember any issues. Small chips, small project, small problems. > Also played with Altera at that time and did not really find one better than > the other, just different. > "Playing" is not enough. To get the feeling about buggyness/robustness of tools one has to do (and complete and probably maintain) complex real-world project. Disclamer: I have no first hand experience with X, so the rest is based on opinions of others. For non-trivial stuff, among which static timing analysis is the most critical, A tools used to be less buggy than X tools. Easier to express yourself as well. And the whole toolchain in general used to make more sense. Now, X is in process of major redesign of their suit (Vivado) and what showed up so far makes good impression. But, according to my understanding, the transition to new tools is not completed yet. And if you are not going to FPGA-only solution then reliability of static timing analysis, esp. of fast interface signals, became a critical part of your project.Article: 156882
Hi, I am planning to install vmWare on one of my server machines and create virtual servers on it. I need to access a Virtex 5 PCIe board from Avnet from the virtual environment. Q1. Does vmWare support accessing third party hardware resources? Q2. Is there a list of devices supported by vmWare? Any links? Q3. Any tutorial/ guide available to do this? RegardsArticle: 156883
Den tirsdag den 15. juli 2014 10.53.43 UTC+2 skrev Tom Gardner: > On 15/07/14 09:31, Stef wrote: > > > In comp.arch.fpga, > > > Tom Gardner <spamjunk@blueyonder.co.uk> wrote: > > >> On 15/07/14 08:18, Stef wrote: > > >>> In comp.arch.fpga, > > >>> Tom Gardner <spamjunk@blueyonder.co.uk> wrote: > > >>>> On 12/07/14 00:33, Stef wrote: > > >>>> 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. ;-) > > >> > > >> My experience... > > >> - site showed two lines > > >> - MicroZed 3 weeks wait > > >> - JTAG cable in stock > > >> - I ordered one of each line > > >> - confirmatory email showed same information > > >> - randomly checking by browsing the order next day showed > > >> JTAG cable 4.5 *MONTHS* delay; both delayed until > > >> both available > > >> - /eventually/ managed to contact a human who nominally > > >> cancelled the JTAG cable > > >> - but cancellation did /not/ show on the order page > > >> > > >> Unacceptable and unnecessary: > > >> - that flip from "available" to 4.5 months after order > > >> - without notice > > >> - cancellation not indicated > > > > > > Unacceptable indeed. If we want to go in this direction, I'll > > > talk to the FAE first and get his thoughts about availablity. > > > Thanks for the warning. > > > > I should add: ordered 18th January, MicroZed shipped > > 1st April, i.e. 11 weeks, not 3. > > > > I suspect that if it is in stock in Europe, then the overall > > experience might be better. Ordering from the US is a pain > > w.r.t. payment of import duties. > > > > > Is the JTAG cable required/recommendend? In a quick read I got > > > the impression that you could just use a micro SD card. > > > > There are several ways of approaching programming and > > debugging the FPGA and ARM. The MicroZed tutorials give a > > good introduction. I found that third party tutorials > > helped (and slightly hindered) me when starting out with > > the (necessarily) complex Xilinx toolset. > > > > For me the SD card would be most useful after the FPGA > > hardware is stable. I don't know how many SD card insertions > > can occur before something is physically damaged. > there is no reason to take the sdcard out all the time if you install a linux you can transfer the configuration file via ethernet and run stuff in a terminal you can mount the boot partition so you can also update the kernel and devicetree without removing the sdcard -LasseArticle: 156884
I'm not sure I explained clearly what is going on.=20 About BRAM1 : - It's a simple-dual port RAM with two address busses, one to write data to= it and the other to read data from it. - It stores all data samples from the ADC irrespective of the trigger. BRAM2 : - It is a single port RAM where the D_OUT of BRAM1 is connected to the D_IN= of the BRAM2 The trigger is basically a register value which goes high. When the value g= oes high, I'm capturing the address of the first address bus of the BRAM1. = I'm offsetting that address to accomodate the pre-trigger data, and then us= e this address value to read data from the BRAM1 and write it to the BRAM2.= =20 I'm generating the addresses using up counters. For the address 1 of the BR= AM1, it is a simple up-counter which just keeps counting up. Now for the se= cond address value of the BRAM1, it would be the =3D (first value - offset)= and then load this value into the counter and count up for a certain numbe= r of samples. Simultaneously, I count up the up-counter for the address of = the BRAM2 and store these trigger samples in BRAM2 until the trigger event = is done.=20 Once the trigger event is done, I stop reading from BRAM1 and also stop the= address counter for BRAM2. Now the up counter has a load and enable signal= . The enable signal is used for counting up while the load signal is used t= o load the start address. For the address counter of the second BRAM, I'm u= sing the trigger event as the enable, but I'm not able to figure out how to= load the address value of the last trigger sample from the previous trigge= r so that I can store the next trigger data, right after the first trigger = data ends. I'm not sure what to use as the load signal. I hope I made more sense this time.=20 On Monday, 14 July 2014 23:51:47 UTC-5, rickman wrote: > On 7/14/2014 3:30 PM, Syed Huq wrote: >=20 > > 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 o= ver the samples including some pre-trigger data to the second BRAM. The sys= tem 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 event= s and not all the data being captured. >=20 > > >=20 > > 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. >=20 > > >=20 > > On Monday, 14 July 2014 13:36:14 UTC-5, Gabor wrote: >=20 > >> Syed Huq wrote: >=20 > >> >=20 > >>> Hi, >=20 > >> >=20 > >>> >=20 > >> >=20 > >>> 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 sample= s 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 sta= rts to count up and lasts only for the duration of the number of samples. T= he 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 = 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 any= one have any suggestions for the logic ? >=20 > >> >=20 > >>> >=20 > >> >=20 > >>> Thanks! >=20 > >> >=20 > >> >=20 > >> >=20 > >> I'd suggest re-thinking the system. Copying data from one BRAM to >=20 > >> >=20 > >> another is an inefficient use of hardware. Why are you doing it? >=20 > >> >=20 > >> Is the idea just to have data from the two most recent triggers? >=20 > >> >=20 > >> If so, then why not just alternate capture between the two BRAM's >=20 > >> >=20 > >> and just keep track of which one was used last. >=20 > >> -- >=20 > >> >=20 > >> Gabor >=20 >=20 >=20 > I'm with Gabor. I think I understand what you are doing and I would say= =20 >=20 > you can do it better without the second BRAM. You are using the entire= =20 >=20 > first BRAM as a circular buffer to capture the data around the trigger.= =20 >=20 > Then you copy just that data around the trigger to the second BRAM for= =20 >=20 > multiple triggers, appending the data each time. >=20 >=20 >=20 > This does not require two BRAMs. If you can't think of how to time the= =20 >=20 > operations and generate the addresses, that shows it is a bit overly=20 >=20 > complex. >=20 >=20 >=20 > I would logically divide one BRAM into multiple circular buffers. The=20 >=20 > first trigger just stores data in the small region allocated for it (the= =20 >=20 > same size as the data you wish to see). The second capture uses the=20 >=20 > second region of the one BRAM and so on. The only complication of this= =20 >=20 > method is that each trigger must save the starting address for the data= =20 >=20 > in the corresponding circular buffer. That could be in the same buffer= =20 >=20 > memory or in a separate buffer. The software that reads out the memory= =20 >=20 > can unwrap the circular buffer as it reads out the data by knowing the=20 >=20 > starting address of the data and the bounds of the circular buffer. >=20 >=20 >=20 > I honestly can't give you a suggestion about your original question=20 >=20 > because I don't understand what you are describing with the addresses=20 >=20 > and registers. You can certainly make the two BRAMs do what you want.=20 >=20 > If you want to do it that way, I just need to understand better what you= =20 >=20 > are describing. >=20 >=20 >=20 > You have a trigger circuit that is filling the first BRAM as a circular= =20 >=20 > buffer. When armed it increments an address register continuously. On= =20 >=20 > the trigger a length counter is started (I would use a down counter)=20 >=20 > that counts the number of samples to store following the trigger. When= =20 >=20 > that counter expires the address register is loaded with the current=20 >=20 > address minus the size of the data you wish to transfer. The length=20 >=20 > counter is also reloaded with the number of samples you wish to transfer= =20 >=20 > and transfers begin to the second BRAM. When the length counter expires= =20 >=20 > a second time the transfers stop. At this point you can either rearm=20 >=20 > the trigger or stop everything and wait for a trigger arming signal. >=20 >=20 >=20 > --=20 >=20 >=20 >=20 > RickArticle: 156885
On Tuesday, July 15, 2014 11:16:42 AM UTC+1, maverick wrote: > Hi, > > I am planning to install vmWare on one of my server machines and create virtual servers on it. I need to access a Virtex 5 PCIe board from Avnet from the virtual environment. Hi, This may not answer your question about vmWare, but I have had to read some of the VirtualBox manual recently and saw this section about PCI pass-through: https://www.virtualbox.org/manual/ch09.html#pcipassthrough So it is certainly possible to virtualize PCI devices in a generic way. I have no idea how well this works or not. Hope this is of some help to you. RupertArticle: 156886
On 7/15/2014 10:36 PM, Syed Huq wrote: > I'm not sure I explained clearly what is going on. > > About BRAM1 : > > - It's a simple-dual port RAM with two address busses, one to write data to it and the other to read data from it. > - It stores all data samples from the ADC irrespective of the trigger. > > BRAM2 : > > - It is a single port RAM where the D_OUT of BRAM1 is connected to the D_IN of the BRAM2 > > The trigger is basically a register value which goes high. When the value goes high, I'm capturing the address of the first address bus of the BRAM1. I'm offsetting that address to accomodate the pre-trigger data, and then use this address value to read data from the BRAM1 and write it to the BRAM2. > > I'm generating the addresses using up counters. For the address 1 of the BRAM1, it is a simple up-counter which just keeps counting up. Now for the second address value of the BRAM1, it would be the = (first value - offset) and then load this value into the counter and count up for a certain number of samples. Simultaneously, I count up the up-counter for the address of the BRAM2 and store these trigger samples in BRAM2 until the trigger event is done. > > Once the trigger event is done, I stop reading from BRAM1 and also stop the address counter for BRAM2. Now the up counter has a load and enable signal.. The enable signal is used for counting up while the load signal is used to load the start address. For the address counter of the second BRAM, I'm using the trigger event as the enable, but I'm not able to figure out how to load the address value of the last trigger sample from the previous trigger so that I can store the next trigger data, right after the first trigger data ends. I'm not sure what to use as the load signal. > > I hope I made more sense this time. > > On Monday, 14 July 2014 23:51:47 UTC-5, rickman wrote: >> 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. I understand what you are doing. You are capturing a small set of samples around a trigger point. My point is that you don't need to use the entire BRAM1 to store what I believe is a smaller set of data you are interested in. How many samples do you transfer to BRAM2? That is as large as you need to make your circular buffer. My point is that you can divide BRAM1 into logical buffers and capture the data into each one without copying anything to a second BRAM. Is that not clear? All you need to do is when the trigger happens, count the additional samples you wish recorded in the circular buffer and stop, then you are done recording and all the data you want is in the buffer. No need to copy it out until it is ready for display. Don't think that a circular buffer has to be as large as the physical BRAM. As to your question, that is a very small detail that depends on the details of your logic. I'm not sure you even need to load an address since the sample blocks can be adjacent in BRAM2. So you can use a single up counter to address BRAM2, incrementing it on every sample stored. It reaches N after moving N samples. So block 2 in BRAM2 will start at location N with the 1st sample in the second block. -- RickArticle: 156887
Hello Everyone I am new to VHDL programming and FPGA. I have a Virtex - 4 FPGA and I wish to generate a binary pulse train of 16 pulses from FPGA using VHDL programming. My desired pulse train will be like "1011100111101110". (min pulse width should be 30ns). I have a clock of 100 MHz and I am able to divide the clock frequency to get the clock of 10MHz (clock frequency required for my application). Also I am aware of the fact that "Wait for" statement can not be used for synthesizing as it can only be used for test bench and simulation purposes. So I am struggling with this problem. I am wondering if I can use "after Xns" command in my VHDL code or if there is any other way to do it. I will be very thankful if any feedback or advice is provided. Your response will truly be appreciated. Kindly provide your valuable suggestions. Thanking you Regards Chaitanya Mauskar --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156888
On 7/22/2014 12:49 PM, chaitanya163 wrote: > Hello Everyone > > I am new to VHDL programming and FPGA. > I have a Virtex - 4 FPGA and I wish to generate a binary pulse train of 16 > pulses from FPGA using VHDL programming. My desired pulse train will be > like "1011100111101110". (min pulse width should be 30ns). > I have a clock of 100 MHz and I am able to divide the clock frequency to > get the clock of 10MHz (clock frequency required for my application). Also > I am aware of the fact that "Wait for" statement can not be used for > synthesizing as it can only be used for test bench and simulation purposes. > > > So I am struggling with this problem. I am wondering if I can use "after > Xns" command in my VHDL code or if there is any other way to do it. > > I will be very thankful if any feedback or advice is provided. Your > response will truly be appreciated. Kindly provide your valuable > suggestions. In order to use an HDL (Hardware Description Language) you need to understand hardware enough that you can then use the HDL to describe it. Think about how you would do this in hardware if you were drawing a schematic. Then you can figure out how to describe that circuit in hardware. So how would you design a circuit using gates and FFs to do this task? -- RickArticle: 156889
Hi, I can give you a quick-and-dirty skeleton in Verilog, just to get you started. module myPulse(input wire clk, input wire rst, output wire sig); always @(posedge clk) begin end endmodule >On 7/22/2014 12:49 PM, chaitanya163 wrote: >> Hello Everyone >> >> I am new to VHDL programming and FPGA. >> I have a Virtex - 4 FPGA and I wish to generate a binary pulse train of 16 >> pulses from FPGA using VHDL programming. My desired pulse train will be >> like "1011100111101110". (min pulse width should be 30ns). >> I have a clock of 100 MHz and I am able to divide the clock frequency to >> get the clock of 10MHz (clock frequency required for my application). Also >> I am aware of the fact that "Wait for" statement can not be used for >> synthesizing as it can only be used for test bench and simulation purposes. >> >> >> So I am struggling with this problem. I am wondering if I can use "after >> Xns" command in my VHDL code or if there is any other way to do it. >> >> I will be very thankful if any feedback or advice is provided. Your >> response will truly be appreciated. Kindly provide your valuable >> suggestions. > >In order to use an HDL (Hardware Description Language) you need to >understand hardware enough that you can then use the HDL to describe it. > Think about how you would do this in hardware if you were drawing a >schematic. Then you can figure out how to describe that circuit in >hardware. > >So how would you design a circuit using gates and FFs to do this task? > >-- > >Rick > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156890
Hi, (browser got trigger-happy, ignore my unfinished previous post if there is any) here's a quick-and-dirty skeleton in Verilog. There are many ways how to approach this, for example use a state machine if it needs to be more complex. This one will load "1" to the output as long as rst is asserted. When rst goes low, the output will play back the sequence and continue with 0. module myPulse(input wire clk, input wire rst, output wire pulseOut); reg [15:0] myReg = 0; assign pulseOut = myReg[15]; always @(posedge clk) begin if (rst) begin myReg <= 16'b1011100111101110; end else begin myReg <= myReg << 1; end end endmodule --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156891
rickman <gnuarm@gmail.com> wrote: > On 7/22/2014 12:49 PM, chaitanya163 wrote: >> I am new to VHDL programming and FPGA. (snip) >> So I am struggling with this problem. I am wondering if I can use "after >> Xns" command in my VHDL code or if there is any other way to do it. (snip) > In order to use an HDL (Hardware Description Language) you need to > understand hardware enough that you can then use the HDL to describe it. > Think about how you would do this in hardware if you were drawing a > schematic. Then you can figure out how to describe that circuit in > hardware. I used to say that you should think about how you would built it using TTL gates, but maybe not everyone knows about TTL by now. You want to think about AND gates and flip-flops. For problems like yours, the most important part could be a shift register, which is a series of flip-flops. -- glenArticle: 156892
chaitanya163 wrote: > My desired pulse train will be > like "1011100111101110". (min pulse width should be 30ns). > I have a clock of 100 MHz and I am able to divide the clock frequency to > get the clock of 10MHz (clock frequency required for my application). You will not be able to get 30 ns pulses with a 10 MHz clock. At least one part of your logic will have to run at a higher clock rate. If you run the logic at 100 MHz, then you will have 10 ns resolution on the bit timing. You could have a 4-bit counter running at 100 MHz/3 = 33 MHz or 30 ns period, and the desired bit pattern entered into a 16:1 multiplexer. The counter selects the inputs in the proper sequence to the multiplexer. Of course, the synthesis tools will do a massive optimization of your description and probably reduce it to about 5 LUTs or so. JonArticle: 156893
mnentwig wrote: > Hi, > > (browser got trigger-happy, ignore my unfinished previous post if there is > any) > > here's a quick-and-dirty skeleton in Verilog. There are many ways how to > approach this, for example use a state machine if it needs to be more > complex. > > This one will load "1" to the output as long as rst is asserted. When rst > goes low, the output will play back the sequence and continue with 0. > > module myPulse(input wire clk, input wire rst, output wire pulseOut); > > reg [15:0] myReg = 0; > assign pulseOut = myReg[15]; > > always @(posedge clk) begin > if (rst) begin > myReg <= 16'b1011100111101110; > end else begin > myReg <= myReg << 1; > end > end > endmodule Ummm, that looks like Verilog, the OP requested VHDL. While the VHDL would not be vastly different, I don't think you can do the << operator quite so concisely in VHDL. I think you can do a loop over the bits and assign myReg<n> <- myReg<n+1> JonArticle: 156894
Le mardi 22 juillet 2014 16:27:41 UTC-3, Jon Elson a =E9crit=A0: > chaitanya163 wrote: > > You will not be able to get 30 ns pulses with a 10 MHz clock. >=20 > At least one part of your logic will have to run at a higher clock >=20 > rate. If you run the logic at 100 MHz, then you will have 10 ns >=20 > resolution on the bit timing. I think 30ns is the minimum pulse size - it may be larger. If so, 10MHz wil= l meet his specifications.Article: 156895
On 7/22/2014 3:30 PM, Jon Elson wrote:
> mnentwig wrote:
>
>> Hi,
>>
>> (browser got trigger-happy, ignore my unfinished previous post if there is
>> any)
>>
>> here's a quick-and-dirty skeleton in Verilog. There are many ways how to
>> approach this, for example use a state machine if it needs to be more
>> complex.
>>
>> This one will load "1" to the output as long as rst is asserted. When rst
>> goes low, the output will play back the sequence and continue with 0.
>>
>> module myPulse(input wire clk, input wire rst, output wire pulseOut);
>>
>> reg [15:0] myReg = 0;
>> assign pulseOut = myReg[15];
>>
>> always @(posedge clk) begin
>> if (rst) begin
>> myReg <= 16'b1011100111101110;
>> end else begin
>> myReg <= myReg << 1;
>> end
>> end
>> endmodule
> Ummm, that looks like Verilog, the OP requested VHDL. While the
> VHDL would not be vastly different, I don't think you can do the
> << operator quite so concisely in VHDL. I think you can do a
> loop over the bits and assign myReg<n> <- myReg<n+1>
I'm sure that would work, but I find constructing a loop to be a bit
wordy. Here is a one line shift register.
myReg <= myReg(myReg'high-1 downto 0) & '0';
That's not so bad is it?
However, this is not an efficient use of resources in an FPGA using up
16 FFs along with the control logic, if any. If it were any larger I
would use a direct address of an array constant would use a four bit
counter and a single LUT used as memory.
constant SerialDataLength : integer := 16;
constant SerialData : unsigned (SerialDataLength-1 downto 0) :=
{'0', '1', '0', '1', '0', '1', '0', '1',
'0', '1', '0', '1', '0', '1', '0', '1'};
signal AddrReg : integer range 0 to SerialDataLength-1;
signal Start : std_logic;
signal CntrEn : std_logic;
AddrGen : process (clk, rst) begin
if (rst = '1') then
Start <= '1';
CntrEn <= '0';
AddrReg <= 0;
elsif (rising_edge(clk)) then
CntrEn <= Start;
if (AddrReg = SerialDataLength-1) then
Start <= '0';
CntrEn <= '0';
end if;
if (CntrEn = '1') then
AddrReg <= (AddrReg + 1) mod SerialDataLength;
end if;
end if;
end process AddrGen ;
Dout <= SerialData (AddrReg) when (Start or Stop = '0') else '0';
This should give you four FF/LUTs for the address register, three for
the control logic and one for the mux selecting the output for a total
of seven LUT/FFs, less than half of what it takes for the shift
register. For longer lengths of shift register the savings are more
pronounced.
--
Rick
Article: 156896On Tue, 22 Jul 2014 18:56:05 +0000, glen herrmannsfeldt wrote: > I used to say that you should think about how you would built it using > TTL gates, but maybe not everyone knows about TTL by now. Indeed. :)Article: 156897
On Saturday, 29 December 2012 00:06:20 UTC, Martin Schoeberl wrote (with s= lightly less compacted blank-lines than this): > Hi all, > started to look into alternatives to Verilog and VHDL and > stumbled over chisel from UCB: >=20 > http://chisel.eecs.berkeley.edu/ >=20 > Any experiences and comment on this language? > >=20 > Looks like some challenge for me as it involves practically > learning 3 new languages at once: chisel itself, Scala on which > it is based, and Verilog, which is produced (I'm used to VHDL). >=20 > Cheers, >=20 > Martin >=20 > PS: I was *very* long absent from this group ;-) I haven't seen mention of PSHDL (pshdl.org) which I have recently come acro= ss via a talk at CCC (German conference), is this worthy of consideration a= lso? Seems it is/can be converted into one of (/both?) the V* languages for= end-use and is aiming to make it easier to learn for beginners (like mysel= f). John.Article: 156898
Hi all, I'm a Berkeley PhD student who has worked extensively with Chisel both in classes and research. I love it, though I did not have much experience with anything else before starting on it. A common description for Chisel I use is "hardware at the word level". It allows for n-dimensional arrays of hardware (wires, gates, modules, whatever). We call it a hardware construction language because it can generate an array of different architectures by changing the input parameters. Another benefit is the cycle-accurate C++ tester, which allows for fast design verification. You do need to learn Chisel and Scala, though they have many similarities. Learning Verilog isn't necessary unless you want to post-process the output for some reason. So maybe it involves only learning 1.5 new languages! There is no VHDL support, nor talk of including it. To attempt remaining unbiased, I'd also like to mention MyHDL, which is an HDL built on Python (a language people are generally more familiar with). If your fear is learning new languages, this might be a good alternative. I know nothing about it save its existence. Thanks! Stevo On 07/24/2014 10:07 AM, jgbreezer@gmail.com wrote: > On Saturday, 29 December 2012 00:06:20 UTC, Martin Schoeberl wrote (with slightly less compacted blank-lines than this): >> Hi all, >> started to look into alternatives to Verilog and VHDL and >> stumbled over chisel from UCB: >> >> http://chisel.eecs.berkeley.edu/ >> >> Any experiences and comment on this language? >> >> >> Looks like some challenge for me as it involves practically >> learning 3 new languages at once: chisel itself, Scala on which >> it is based, and Verilog, which is produced (I'm used to VHDL). >> >> Cheers, >> >> Martin >> >> PS: I was *very* long absent from this group ;-) > > > I haven't seen mention of PSHDL (pshdl.org) which I have recently come across via a talk at CCC (German conference), is this worthy of consideration also? Seems it is/can be converted into one of (/both?) the V* languages for end-use and is aiming to make it easier to learn for beginners (like myself). > > John. >Article: 156899
Hi all, Can you suggest any good FPGA projects I could contribute to? I have some = free time and want to work on something challenging and interesting. Inste= ad of starting something myself I'm wondering where to find some cool proje= cts that exist already that need help. Thanks!
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