Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 156650

Article: 156650
Subject: Re: Microblaze and MBLite
From: al.basili@gmail.com (alb)
Date: 23 May 2014 06:28:57 GMT
Links: << >>  << T >>  << A >>
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.

Al

Article: 156651
Subject: Re: need coding
From: Saqib Saqi <saqi0313saqi@gmail.com>
Date: Fri, 23 May 2014 16:33:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 me 

Article: 156652
Subject: Signal Integrity Failure on Custom FPGA board
From: dc2uv.design@gmail.com
Date: Sun, 25 May 2014 01:09:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Microblaze and MBLite
From: mariam.makni@gmail.com
Date: Sun, 25 May 2014 08:53:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: integrate microblaze in ISE and VHDL code
From: "rody786" <100283@embeddedrelated>
Date: Sun, 25 May 2014 15:36:10 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 156655
Subject: Re: Microblaze and MBLite
From: al.basili@gmail.com (alb)
Date: 27 May 2014 06:27:37 GMT
Links: << >>  << T >>  << A >>
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,

Al

Article: 156656
Subject: FSL Bus Problem
From: mouna <manou.makni@gmail.com>
Date: Tue, 27 May 2014 05:10:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Microblaze and MBLite
From: Mariem Makni <mariam.makni@gmail.com>
Date: Tue, 27 May 2014 05:28:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Trigger implementation on ADC-FPGA
From: Syed Huq <syed.huq.a@gmail.com>
Date: Tue, 27 May 2014 09:49:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Trigger implementation on ADC-FPGA
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 27 May 2014 13:27:42 -0400
Links: << >>  << T >>  << A >>
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

Article: 156660
Subject: Re: Trigger implementation on ADC-FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 27 May 2014 13:41:29 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 156661
Subject: Re: Microblaze and MBLite
From: al.basili@gmail.com (alb)
Date: 27 May 2014 19:26:33 GMT
Links: << >>  << T >>  << A >>
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.

Al

Article: 156662
Subject: Re: Trigger implementation on ADC-FPGA
From: Tim Wescott <tim@seemywebsite.really>
Date: Tue, 27 May 2014 19:13:03 -0500
Links: << >>  << T >>  << A >>
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.com


Article: 156663
Subject: Re: Quartus II under Windows7?
From: imtiazali77@gmail.com
Date: Tue, 27 May 2014 23:35:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Microblaze and MBLite
From: Mariem Makni <mariam.makni@gmail.com>
Date: Wed, 28 May 2014 01:52:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Trigger implementation on ADC-FPGA
From: Syed Huq <syed.huq.a@gmail.com>
Date: Wed, 28 May 2014 09:12:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Trigger implementation on ADC-FPGA
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 28 May 2014 14:13:49 -0400
Links: << >>  << T >>  << A >>
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.

-- 
Gabor

Article: 156667
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 28 May 2014 21:49:35 +0100
Links: << >>  << T >>  << A >>
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
Subject: shift register (invariable size) FIFO = ?
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 31 May 2014 13:46:11 -0500
Links: << >>  << T >>  << A >>
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

Article: 156669
Subject: Re: shift register (invariable size) FIFO = ?
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 31 May 2014 15:08:43 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: shift register (invariable size) FIFO = ?
From: "mnentwig" <24789@embeddedrelated>
Date: Sun, 01 Jun 2014 01:04:05 -0500
Links: << >>  << T >>  << A >>
Thanks! "Delay line" it shall be then.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156671
Subject: Re: Zynq devices, boards and suppliers
From: colin <colin_toogood@yahoo.com>
Date: Mon, 2 Jun 2014 07:00:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Colin

Article: 156672
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 02 Jun 2014 15:59:46 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Trigger implementation on ADC-FPGA
From: Syed Huq <syed.huq.a@gmail.com>
Date: Mon, 2 Jun 2014 11:43:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
> Gabor


Article: 156674
Subject: Re: Trigger implementation on ADC-FPGA
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 02 Jun 2014 20:10:48 +0100
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search