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
Mark Curry <gtwrek@sonic.net> wrote: [] >>My goal is to connect >>the MBLite opencore processor to the Xilinx Microblaze. The problem is that >>MBLite support only Wishbone bus as interface or the Microblaze can support >>FSL and PLB Bus. [] you'd need to find bridges to a commonly supported bus. IIRC on opencores there are bridges from/to wishbone/amba. > > You'll have to give a few more details. Just what are you trying to do? > Perusing the opencores website, I see that the MBlite is just an open > source version of the Microblaze itself. It's probably not > identical but close enough the the Xilinx Microblaze. Looks like > whomever created it wanted a mblaze in Altera FPGAs. The rationale behind the MBlite is to provide a platform which is 'lite' w.r.t. the MicroBlaze and open such that research groups can play with it freely. Not all MicroBlaze OPCODES are supported, but is highly configurable, with options to include/exclude hardware as needed. We are currently using it with the addition of an hardware FPU. AlArticle: 156651
On Saturday, May 17, 2014 6:55:11 AM UTC+5, Walter Banks wrote: > Saqib Saqi wrote: > > > > > @mnentwig > > > our univ. can't paid for our project . > > > they only provide the equipment ..if only they r available in our labzz > > > > There are many here who will help you but you need to start by being an > > engineer. > > > > Lets start by getting a design document together. A simple document of > > project goals and solutions. > > > > Start with a simple description of goals > > > > Add to it some lists to get started. > > 1) What information you need to do this project. > > 2) What information do you have? > > 3) Where can you find the rest of the information? > > possible answers > > - It is a standard > > - It is available by a google search. > > - Don't know. (This group may be able to give you hints if you ask) > > > > Start the engineering > > What resources are needed. > > Time available to execute one cycle > > Code size constraints > > Data size constraints > > Tools needed to do the implementation > > How are you going to test it > > What is the critical part that everything else depends on > > Sketch out the all of the pieces needed for a solution > > > > > > Design documents can be any convenient form. > > The purpose of design documents is to focus your thinking. > > I use either a spread sheet as an electronic blackboard or text/graphic > > editor. > > > > There are no short cuts. > > > > If you ask an engineering question, this group will help. > > The solution needs to be yours > > > > w.. @walter i don't have any system generator design can u provide meArticle: 156652
Is it possible you have the pin assignments mixed up, having TMS toggle faster than TCK is a little unusual? Other than that an open/short on any of the signals could result in the error you see.Article: 156653
Le vendredi 23 mai 2014 08:28:57 UTC+2, alb a =E9crit=A0: > Mark Curry <gtwrek@sonic.net> wrote: >=20 > [] >=20 > >>My goal is to connect >=20 > >>the MBLite opencore processor to the Xilinx Microblaze. The problem is = that >=20 > >>MBLite support only Wishbone bus as interface or the Microblaze can sup= port >=20 > >>FSL and PLB Bus.=20 >=20 > [] >=20 >=20 >=20 > you'd need to find bridges to a commonly supported bus. IIRC on=20 >=20 > opencores there are bridges from/to wishbone/amba. >=20 >=20 >=20 > >=20 >=20 > > You'll have to give a few more details. Just what are you trying to do= ? =20 >=20 > > Perusing the opencores website, I see that the MBlite is just an open >=20 > > source version of the Microblaze itself. It's probably not >=20 > > identical but close enough the the Xilinx Microblaze. Looks like=20 >=20 > > whomever created it wanted a mblaze in Altera FPGAs. >=20 >=20 >=20 > The rationale behind the MBlite is to provide a platform which is 'lite'= =20 >=20 > w.r.t. the MicroBlaze and open such that research groups can play with=20 >=20 > it freely. >=20 >=20 >=20 > Not all MicroBlaze OPCODES are supported, but is highly configurable,=20 >=20 > with options to include/exclude hardware as needed. We are currently=20 >=20 > using it with the addition of an hardware FPU. >=20 >=20 >=20 > Al Hi, Thank for your help. It's clear now that i must use a bridge PLB to wishbone for connecting the = MB Lite to Microblaze. I have a question about how programming and execute a C code for MBLite on = FPGA? because I'm using the EDK and I want to compile and execute a C code = to MBLite, knowing that for Microblaze, it is easy because this later suppo= rt the LMB Bus to connect to the local memory but how can I do this for MB = Lite in the EDK? Thanks in advance.Article: 156654
Dear all, I'm beginner to use microblaze. I made a simple program to read two numbers from uart and add them using microblaze. For further purposes I want to integrate the microblaze as subcomponnet in a top level VHDL code, I need to get the two numbers read from the uart (for the microblaze operation) in another vhdl component. How could I do that?? Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156655
Hi Mariam, mariam.makni@gmail.com wrote: [] > It's clear now that i must use a bridge PLB to wishbone for connecting > the MB Lite to Microblaze. I have a question about how programming and > execute a C code for MBLite on FPGA? because I'm using the EDK and I > want to compile and execute a C code to MBLite, knowing that for > Microblaze, it is easy because this later support the LMB Bus to > connect to the local memory but how can I do this for MB Lite in the > EDK? I do not know EDK so I cannot help you here. We are using gcc for microblaze (microblaze-xilinx-elf-4.1.1) and created simple software utilities to convert the binary image into memory mapping (see opencores trunk, under sw). That works well with simulation, so you can compile a piece of software and run it in your sim. How to load the memory mapping onto your physical memory I cannot help because it depends on your interface. We transfer program image into memory via 1553. HTH, AlArticle: 156656
Hi everybody, I have connected a coprocessor to Microblaze in EDK through FSL. My problem is when i read data from FSL Bus; I do not get data from my ip from fsl. I want to know how can I simulate the whole system (microblaze & coprocessor) and see what is happening on the FSL bus. Thanks in advance.Article: 156657
Le mardi 27 mai 2014 08:27:37 UTC+2, alb a =E9crit=A0: > Hi Mariam, >=20 > mariam.makni@gmail.com wrote: >=20 > [] >=20 > > It's clear now that i must use a bridge PLB to wishbone for connecting= =20 >=20 > > the MB Lite to Microblaze. I have a question about how programming and= =20 >=20 > > execute a C code for MBLite on FPGA? because I'm using the EDK and I=20 >=20 > > want to compile and execute a C code to MBLite, knowing that for=20 >=20 > > Microblaze, it is easy because this later support the LMB Bus to=20 >=20 > > connect to the local memory but how can I do this for MB Lite in the=20 >=20 > > EDK? >=20 >=20 >=20 > I do not know EDK so I cannot help you here. We are using gcc for=20 >=20 > microblaze (microblaze-xilinx-elf-4.1.1) and created simple software=20 >=20 > utilities to convert the binary image into memory mapping (see opencores= =20 >=20 > trunk, under sw). >=20 >=20 >=20 > That works well with simulation, so you can compile a piece of software= =20 >=20 > and run it in your sim. How to load the memory mapping onto your=20 >=20 > physical memory I cannot help because it depends on your interface. We=20 >=20 > transfer program image into memory via 1553. >=20 >=20 >=20 > HTH, >=20 >=20 >=20 > Al Thanks a lot for your reply. So, do you use ISE xilinx instead of EDK to run an application for MBLite?Article: 156658
Hi, I'm trying to implement hardware trigger functionality by modifying the FPG= A code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA,= and then implementing it on our custom board but I had a few questions wit= h regards to it.=20 From what I understand of how the trigger works, the data keeps being captu= red continuously by the ADC, but the trigger functionality would only kick = in when the data is being stored. Am I right in that assumption? Maybe I ne= ed to keep checking the trigger and only when the board is triggered, I all= ow the data to be stored inside the internal RAM of the FPGA? Or is there a= n alternate way to do this? I'm currently storing the data samples using th= e Block RAM of the FPGA.=20 If my thinking is right, when the the board is triggered, and the data star= ts being captured, I lose a few data samples due to the delay in the trigge= r registering and then the data being stored. How do I overcome this? Even = a few nanoseconds of data is important in this case. I'd appreciate any ideas on this. Thanks!Article: 156659
Syed Huq wrote: > Hi, > > I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it. > > From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA. > > If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case. > > I'd appreciate any ideas on this. Thanks! The standard way to do capture that includes the trigger event is to continuously store all data in a ring buffer. When the trigger occurs you continue storing data for some length of time, but not enough to wrap around the whole buffer and overwrite the trigger event. For example, if you have a 2K deep BRAM buffer (2K samples, that is) then you'd have an 11-bit write pointer that continuously places each consequtive sample at the next location in BRAM, wrapping to location 0 after writing location 2047. Now if you want to capture 10 samples before a trigger and the remaining 2038 samples after the trigger, you'd just keep storing samples in the buffer for another 2038 samples after triggering (you might need to adjust that based on the trigger delay). When you're done, the write pointer stops incrementing and you stop storing data. If your write pointer increments after the last write, it will be pointing to the oldest data in the buffer. The newest data will be at the previous location. The sample that occured closest to the trigger event would be at the write pointer + 10. -- GaborArticle: 156660
On 5/27/2014 12:49 PM, Syed Huq wrote: > Hi, > > I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it. > > From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA. > > If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case. > > I'd appreciate any ideas on this. Thanks! Your trigger can do anything you wish. Typically a device like this will store data into memory continuously in a wrap around buffer while waiting for the trigger. Then when the trigger is detected the address of the appropriate sample is noted and collection continues until the desired amount of data is stored. On oscilloscopes they do this and allow the user to select the amount of data to be retained from before the trigger. If you don't need any significant amount of data from before the trigger, then you can use a simple FIFO buffer to hold the N samples that would be missed because of the trigger delay. Essentially this is a small wrap around buffer. -- RickArticle: 156661
Hi Mariem, Mariem Makni <mariam.makni@gmail.com> wrote: [] > Thanks a lot for your reply. > So, do you use ISE xilinx instead of EDK to run an application for MBLite? My target is a Microsemi device, nothing to do with Xilinx. For that matter I try not to use Integrated Environments as much as possible. If I want to run the application in a simulation I simply map the memory content I use the following: mem load -infile rom.mem -format hex /imem/ram mem load -infile rom0.mem -format hex /dmem/mem__0/mem mem load -infile rom1.mem -format hex /dmem/mem__1/mem mem load -infile rom2.mem -format hex /dmem/mem__2/mem mem load -infile rom3.mem -format hex /dmem/mem__3/mem in my *.do file for ModelSim. Otherwise I use the binary content of rom?.mem files and load them at the appropriate address in my memory through 1553. AlArticle: 156662
On Tue, 27 May 2014 09:49:04 -0700, Syed Huq wrote: > Hi, > > I'm trying to implement hardware trigger functionality by modifying the > FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 > FPGA, and then implementing it on our custom board but I had a few > questions with regards to it. > > From what I understand of how the trigger works, the data keeps being > captured continuously by the ADC, but the trigger functionality would > only kick in when the data is being stored. Am I right in that > assumption? Maybe I need to keep checking the trigger and only when the > board is triggered, I allow the data to be stored inside the internal > RAM of the FPGA? Or is there an alternate way to do this? I'm currently > storing the data samples using the Block RAM of the FPGA. > > If my thinking is right, when the the board is triggered, and the data > starts being captured, I lose a few data samples due to the delay in the > trigger registering and then the data being stored. How do I overcome > this? Even a few nanoseconds of data is important in this case. > > I'd appreciate any ideas on this. Thanks! You want something that's sorta kinda like an oscilloscope? In "wait for trigger" mode, store data all the time, to a circular buffer in memory. When you get a trigger event, count out some number of samples, then stop storing data. Then when you read out the buffer, alias it so that the oldest sample is 0, the next is 1, etc. This way, you can even capture data before the trigger event, if that's important. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156663
> First of all, thanks to everyone for all the on point suggestions - > much appreciated! Altium support got back to me last night with the > following: > > "Check the 'Ignore version of vendor tools' in DXP---Preferences--- > FPGA---Devices View. > Thanks it helped me to correct the problem on my windows 7 64bit....Article: 156664
Le mardi 27 mai 2014 21:26:33 UTC+2, alb a =E9crit=A0: > Hi Mariem, >=20 > Mariem Makni <mariam.makni@gmail.com> wrote: >=20 > [] >=20 > > Thanks a lot for your reply. >=20 > > So, do you use ISE xilinx instead of EDK to run an application for MBLi= te? >=20 >=20 >=20 > My target is a Microsemi device, nothing to do with Xilinx. For that=20 >=20 > matter I try not to use Integrated Environments as much as possible. >=20 >=20 >=20 > If I want to run the application in a simulation I simply map the memory= =20 >=20 > content I use the following: >=20 >=20 >=20 > mem load -infile rom.mem -format hex /imem/ram >=20 > mem load -infile rom0.mem -format hex /dmem/mem__0/mem >=20 > mem load -infile rom1.mem -format hex /dmem/mem__1/mem >=20 > mem load -infile rom2.mem -format hex /dmem/mem__2/mem >=20 > mem load -infile rom3.mem -format hex /dmem/mem__3/mem >=20 >=20 >=20 > in my *.do file for ModelSim. >=20 >=20 >=20 > Otherwise I use the binary content of rom?.mem files and load them at=20 >=20 > the appropriate address in my memory through 1553. >=20 >=20 >=20 > Al Thanks a lot for your detailed explanation and guidance.Article: 156665
On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor wrote: > Syed Huq wrote: >=20 > > Hi, >=20 > >=20 >=20 > > I'm trying to implement hardware trigger functionality by modifying the= FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 F= PGA, and then implementing it on our custom board but I had a few questions= with regards to it.=20 >=20 > >=20 >=20 > > From what I understand of how the trigger works, the data keeps being c= aptured continuously by the ADC, but the trigger functionality would only k= ick in when the data is being stored. Am I right in that assumption? Maybe = I need to keep checking the trigger and only when the board is triggered, I= allow the data to be stored inside the internal RAM of the FPGA? Or is the= re an alternate way to do this? I'm currently storing the data samples usin= g the Block RAM of the FPGA.=20 >=20 > >=20 >=20 > > If my thinking is right, when the the board is triggered, and the data = starts being captured, I lose a few data samples due to the delay in the tr= igger registering and then the data being stored. How do I overcome this? E= ven a few nanoseconds of data is important in this case. >=20 > >=20 >=20 > > I'd appreciate any ideas on this. Thanks! >=20 >=20 >=20 > The standard way to do capture that includes the trigger event is to >=20 > continuously store all data in a ring buffer. When the trigger occurs >=20 > you continue storing data for some length of time, but not enough to >=20 > wrap around the whole buffer and overwrite the trigger event. For >=20 > example, if you have a 2K deep BRAM buffer (2K samples, that is) then >=20 > you'd have an 11-bit write pointer that continuously places each >=20 > consequtive sample at the next location in BRAM, wrapping to location >=20 > 0 after writing location 2047. Now if you want to capture 10 samples >=20 > before a trigger and the remaining 2038 samples after the trigger, >=20 > you'd just keep storing samples in the buffer for another 2038 samples >=20 > after triggering (you might need to adjust that based on the trigger >=20 > delay). When you're done, the write pointer stops incrementing and >=20 > you stop storing data. If your write pointer increments after the >=20 > last write, it will be pointing to the oldest data in the buffer. >=20 > The newest data will be at the previous location. The sample that >=20 > occured closest to the trigger event would be at the write pointer + 10. >=20 >=20 >=20 > --=20 >=20 > Gabor Thanks for the detailed explanation. To explain the code better, the sample= s are captured by the ADC, they are remapped by the ADC Remapper and the sa= mples are stored in 256 bit x 8192 BRAM. The address for the BRAM is genera= ted by up-counters. So on the trigger, would I just record the address at t= hat particular time and store samples for maybe the next 8K depth in order = to preserve roughly ~200 depth of samples before the trigger ? I'm not part= icularly sure if the addresses are recycled again since I'm still trying to= understand the code provided by TI for the board.Article: 156666
Syed Huq wrote: > On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor wrote: >> Syed Huq wrote: >> >>> Hi, >>> I'm trying to implement hardware trigger functionality by modifying the FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5 FPGA, and then implementing it on our custom board but I had a few questions with regards to it. >>> From what I understand of how the trigger works, the data keeps being captured continuously by the ADC, but the trigger functionality would only kick in when the data is being stored. Am I right in that assumption? Maybe I need to keep checking the trigger and only when the board is triggered, I allow the data to be stored inside the internal RAM of the FPGA? Or is there an alternate way to do this? I'm currently storing the data samples using the Block RAM of the FPGA. >>> If my thinking is right, when the the board is triggered, and the data starts being captured, I lose a few data samples due to the delay in the trigger registering and then the data being stored. How do I overcome this? Even a few nanoseconds of data is important in this case. >>> I'd appreciate any ideas on this. Thanks! >> >> >> The standard way to do capture that includes the trigger event is to >> >> continuously store all data in a ring buffer. When the trigger occurs >> >> you continue storing data for some length of time, but not enough to >> >> wrap around the whole buffer and overwrite the trigger event. For >> >> example, if you have a 2K deep BRAM buffer (2K samples, that is) then >> >> you'd have an 11-bit write pointer that continuously places each >> >> consequtive sample at the next location in BRAM, wrapping to location >> >> 0 after writing location 2047. Now if you want to capture 10 samples >> >> before a trigger and the remaining 2038 samples after the trigger, >> >> you'd just keep storing samples in the buffer for another 2038 samples >> >> after triggering (you might need to adjust that based on the trigger >> >> delay). When you're done, the write pointer stops incrementing and >> >> you stop storing data. If your write pointer increments after the >> >> last write, it will be pointing to the oldest data in the buffer. >> >> The newest data will be at the previous location. The sample that >> >> occured closest to the trigger event would be at the write pointer + 10. >> >> >> >> -- >> >> Gabor > > Thanks for the detailed explanation. To explain the code better, the samples are captured by the ADC, they are remapped by the ADC Remapper and the samples are stored in 256 bit x 8192 BRAM. The address for the BRAM is generated by up-counters. So on the trigger, would I just record the address at that particular time and store samples for maybe the next 8K depth in order to preserve roughly ~200 depth of samples before the trigger ? I'm not particularly sure if the addresses are recycled again since I'm still trying to understand the code provided by TI for the board. If by 8K you mean 8,000 and not 8,192 then what you said is correct. As for recycling the address, any simple up-counter would go back to zero after it reaches 8,191. The real question is whether the counter and BRAM write enable are active all the time, or just after you trigger the core. Of course you'd need to look through the code or ask someone at TI if that is the case. -- GaborArticle: 156667
I'd like to make a couple of comments based on my experience, in the hope they might be helpful to other netizens. In the end I purchased an Avnet MicroZed and JTAG cable in January. The ordering process was smooth but the delivery wasn't. An email confirmed the stated 3 week delay for the MicroZed, and that the JTAG cable /was/ in stock. However, the next day the website showed an 18(!) delay until May. I quickly cancelled the now out of stock JTAG cable, and the MicroZed turned up in March, after maybe 8 weeks. That is unacceptable and makes me unlikely to choose to use Avnet as a distributor. More positively, the MicroZed documentation and support have been exemplary; the potential concerns I raised in the note below haven't been bourne out. Indeed Avnet have expanded their range and appear to be making concerted efforts to make a business in this area. So far I have /no/ concerns about having chosen to use a MicroZed, although nowadays I would probably choose to use the MicroZed SBC board variant. On 16/10/13 12:28, Tom Gardner wrote: > I'd like to pick people's brains about aspects of > different *suppliers* of Zynq boards. Avnet and Digilent > are front-runners, but any info/opinions about other > suppliers would be helpful too. > > - ease of using their embedded linux. My needs > are simple, requiring a shell and TCP/IP protocols > over ethernet. GUI not required, but might be > used if it didn't complicate the development. > > - quality of online support. How easy is it > likely to be to find the information so that > I can (a) duplicate any supplied demo environment > and (b) mutate it so that my code accesses my > programmable logic > > - board production longevity. I'm not concerned > about decades, but I would be concerned if a > board was unobtainable within months > > - ISE or Vivado environment > > Background and context... > > I'm intending to develop something based around a small > Xylinx Zynq device. Cost is an issue, but not to the > extent that I will be developing a board containing > the FPGA itself. I will, however, be developing a small > simple add-on board containing my analogue circuits. > > Now I can read a datasheet and schematic and outline > to determine the extent to which a board is suitable. > However, as we are all aware, those documents /don't/ > cover all the important points when choosing a board! > > I've created many stand-alone hardware and software > embedded systems, but *not* based on linux *nor* on ARM > *nor* in the Xilinx ecosystem. Since Zynq devices > represent a complex environment, I'll have a learning > curve (good, I like challenges), and I'm interested > in the quality of the resources and support that > I'll need to overcome my misapprehensions.Article: 156668
Hi, if I chain up a bunch or registers (or use shift registers), the data comes out only after it has passed through the whole memory length. Even though "first in" comes out first, at least [1] states on page 2 that this is usually not referred to as "a" FIFO . On the other hand, a "conventional" memory-based FIFO gives the output more or less immediately, as it has variable size. My question is, do those two types of memories have commonly accepted names to distinguish between them, for example when commenting code? I was about to call the "invariable size" variant a "pipe", but maybe there is a better term? [1] http://www.ti.com/lit/an/scaa042a/scaa042a.pdf --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156669
On 5/31/14, 2:46 PM, mnentwig wrote: > Hi, > > if I chain up a bunch or registers (or use shift registers), the data comes > out only after it has passed through the whole memory length. Even though > "first in" comes out first, at least [1] states on page 2 that this is > usually not referred to as "a" FIFO . > On the other hand, a "conventional" memory-based FIFO gives the output more > or less immediately, as it has variable size. > > My question is, do those two types of memories have commonly accepted names > to distinguish between them, for example when commenting code? > I was about to call the "invariable size" variant a "pipe", but maybe there > is a better term? > > [1] http://www.ti.com/lit/an/scaa042a/scaa042a.pdf > > > --------------------------------------- > Posted through http://www.FPGARelated.com > A block where the data comes out N cycles after it goes in is generally (at least in my experience) called a pipeline, delay line, or shift register. The key difference between this sort of module and a FIFO, is that a FIFO generally runs "intermittently", where at least one (but normally both) of the input or the output only transfers data on some control signal. A Pipeline tends to always run, though sometimes there is a "Hold" signal that stops the shifting.Article: 156670
Thanks! "Delay line" it shall be then. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156671
I'd really like to buy a microzed. $199 in USA, but buy from Europe for an eye watering $321. The checkout page gives Dollars and Euros so I can't see any form of typo. ColinArticle: 156672
On 02/06/14 15:00, colin wrote: > I'd really like to buy a microzed. $199 in USA, but buy from Europe for an eye watering $321. The checkout page gives Dollars and Euros so I can't see any form of typo. I bought from the US. Costs were: - $199 MicroZed - $48 shipping (Fedex) - £24 VAT, paid by fedex, reimbursed by me... - £11 Fedex fee So the grand total was around £184 or approx $313. The fedex overhead fee rankled, but there wasn't much I could do about it.Article: 156673
Well the folks at TI are not much help since they themselves outsourced the= coding for the FPGA. The way I want the Trigger to work is that, when the = trigger occurs, the data samples are stored for a few seconds. I also want = to ensure that there is a bit of hold-off time within which another trigger= cannot occur. How would I do that ? On Wednesday, 28 May 2014 13:13:49 UTC-5, Gabor wrote: > Syed Huq wrote: >=20 > > On Tuesday, 27 May 2014 12:27:42 UTC-5, Gabor wrote: >=20 > >> Syed Huq wrote: >=20 > >> >=20 > >>> Hi, >=20 > >>> I'm trying to implement hardware trigger functionality by modifying t= he FPGA code for the LM97600RB from Texas Instruments which uses a Virtex-5= FPGA, and then implementing it on our custom board but I had a few questio= ns with regards to it.=20 >=20 > >>> From what I understand of how the trigger works, the data keeps being= captured continuously by the ADC, but the trigger functionality would only= kick in when the data is being stored. Am I right in that assumption? Mayb= e I need to keep checking the trigger and only when the board is triggered,= I allow the data to be stored inside the internal RAM of the FPGA? Or is t= here an alternate way to do this? I'm currently storing the data samples us= ing the Block RAM of the FPGA.=20 >=20 > >>> If my thinking is right, when the the board is triggered, and the dat= a starts being captured, I lose a few data samples due to the delay in the = trigger registering and then the data being stored. How do I overcome this?= Even a few nanoseconds of data is important in this case. >=20 > >>> I'd appreciate any ideas on this. Thanks! >=20 > >> >=20 > >> >=20 > >> The standard way to do capture that includes the trigger event is to >=20 > >> >=20 > >> continuously store all data in a ring buffer. When the trigger occurs >=20 > >> >=20 > >> you continue storing data for some length of time, but not enough to >=20 > >> >=20 > >> wrap around the whole buffer and overwrite the trigger event. For >=20 > >> >=20 > >> example, if you have a 2K deep BRAM buffer (2K samples, that is) then >=20 > >> >=20 > >> you'd have an 11-bit write pointer that continuously places each >=20 > >> >=20 > >> consequtive sample at the next location in BRAM, wrapping to location >=20 > >> >=20 > >> 0 after writing location 2047. Now if you want to capture 10 samples >=20 > >> >=20 > >> before a trigger and the remaining 2038 samples after the trigger, >=20 > >> >=20 > >> you'd just keep storing samples in the buffer for another 2038 samples >=20 > >> >=20 > >> after triggering (you might need to adjust that based on the trigger >=20 > >> >=20 > >> delay). When you're done, the write pointer stops incrementing and >=20 > >> >=20 > >> you stop storing data. If your write pointer increments after the >=20 > >> >=20 > >> last write, it will be pointing to the oldest data in the buffer. >=20 > >> >=20 > >> The newest data will be at the previous location. The sample that >=20 > >> >=20 > >> occured closest to the trigger event would be at the write pointer + 1= 0. >=20 > >> >=20 > >> >=20 > >> >=20 > >> --=20 >=20 > >> >=20 > >> Gabor >=20 > >=20 >=20 > > Thanks for the detailed explanation. To explain the code better, the sa= mples are captured by the ADC, they are remapped by the ADC Remapper and th= e samples are stored in 256 bit x 8192 BRAM. The address for the BRAM is ge= nerated by up-counters. So on the trigger, would I just record the address = at that particular time and store samples for maybe the next 8K depth in or= der to preserve roughly ~200 depth of samples before the trigger ? I'm not = particularly sure if the addresses are recycled again since I'm still tryin= g to understand the code provided by TI for the board. >=20 >=20 >=20 > If by 8K you mean 8,000 and not 8,192 then what you said is correct. As >=20 > for recycling the address, any simple up-counter would go back to zero >=20 > after it reaches 8,191. The real question is whether the counter and >=20 > BRAM write enable are active all the time, or just after you trigger the >=20 > core. Of course you'd need to look through the code or ask someone >=20 > at TI if that is the case. >=20 >=20 >=20 > --=20 >=20 > GaborArticle: 156674
On 02/06/14 19:43, Syed Huq wrote: > The way I want the Trigger to work is that, when the trigger occurs, > the data samples are stored for a few seconds.I also want to ensure > that there is a bit of hold-off time within which another trigger > cannot occur. How would I do that ? With a finite state machine, a clock, and a few counters.
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