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
<news-support@sbcglobal.net> wrote in message news:1244504405.96258_3078@flph199.ffdc.sbc.com... > > Please note that on or around July 15, 2009, AT&T will no longer be > offering access to the Usenet netnews service. If you wish to continue > reading Usenet newsgroups, access is available through third-party > vendors. > > Posted only internally to AT&T Usenet Servers. Well there's a bite in the nuts. Thanks a bunch.Article: 141151
Hi, I am reading the book "Digital Signal Processing with Field Programmable Gate Arrays" 3rd. However, the included CD-ROM and manual are missing and the link http://hometown.aol.de/uwemeyerbaese is not working anymore. Anyone knows where I can download the source code/manual for this book? Best Regards, TomArticle: 141152
On Tue, 9 Jun 2009 12:40:43 +0800, "david wang" <wdavidt@hotmail.com> wrote: |Hi, | |I am reading the book "Digital Signal Processing with Field Programmable |Gate Arrays" 3rd. |However, the included CD-ROM and manual are missing and the link |http://hometown.aol.de/uwemeyerbaese is not working anymore. |Anyone knows where I can download the source code/manual for this book? | |Best Regards, | |Tom |================== AOL shut down their webhosting a while back so all those links that start with "hometown.aol." are no longer active. Best guess is to google his name and try that route. jamesArticle: 141153
On Jun 9, 9:38=A0am, james <geo...@washington.edu> wrote: > On Tue, 9 Jun 2009 12:40:43 +0800, "david wang" <wdav...@hotmail.com> > wrote: > > |Hi, > | > |I am reading the book "Digital Signal Processing with Field Programmable > |Gate Arrays" 3rd. > |However, the included CD-ROM and manual are missing and the link > |http://hometown.aol.de/uwemeyerbaeseis not working anymore. > |Anyone knows where I can download the source code/manual for this book? > | > |Best Regards, > | > |Tom > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > AOL shut down their webhosting a while back so all those links that > start with "hometown.aol." are no longer active. > > Best guess is to google his name and try that route. > > james The internet archive at www.archive.org is a wonderful thing. Searching it for the address http://hometown.aol.de/uwemeyerbaese/index.htm= l yields this link: http://web.archive.org/web/20071207102441/http://hometown.aol.de/uwemeyerba= ese/index.html Hope this helps. DaveArticle: 141154
maxascent wrote:
> Why dont they just let you use your own
> download manger?
I got the DVD. 'free' for a $7 shipping charge.
-- Mike Treseler
Article: 141155On Jun 8, 3:11=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > I was trying to download ISE 11.1 using their download manager, and manag= ed > to get to 50% when it came up with an error. So I left it while the next > day and tried to start again from 50% but was still getting the error. I > thought maybe their website was down but it cant be as I have been able t= o > start a new download from the beginning. This seems crazy to me that thei= r > download manager is not working correctly and you end up losing all the > data that you have already got. Why dont they just let you use your own > download manger? > > Jon This issue has been discussed on <a href=3D"http://forums.xilinx.com/ xlnx/board/message? board.id=3DGenDis&message.id=3D1581&query.id=3D491264#M1581">XIlinx forums<= / a>. I've got is as well. What I can suggest is to try to download from different browsers : IE, FF or Chrome. - outputlogicArticle: 141156
On Jun 8, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > But I dont understand why Xilinx have put this 100ps delay in the output > that doesnt seems to relate to anything in the Virtex 5 datasheet. > > Jon Why do you think there is no delay in the real part? No matter where you measure it, there will be some delay. It is hard to measure delays inside the FPGA, so they only spec delays they can verify externally. If you look at the timing diagrams in the data sheet, they don't show the data out of a memory changing exactly on the clock edge. They show it changing some time later as it would in any real part. Besides, why are you worried about this? You are not doing a timing simulation, which is pretty pointless anyway. So where is the problem? RickArticle: 141157
rickman wrote:
> Why do you think there is no delay in the real part? No matter where
> you measure it, there will be some delay.
True, but the exact delay is unknown until place and route.
I prefer to to leave it as a delta delay for the description
and let synthesis fill in the real value for STA or backanno.
-- Mike Treseler
Article: 141158I'm giving it another go so hopefully it will be ok this time. Was going to get the dvd but it costs a lot more to ship to the UK and takes 3 weeks. JonArticle: 141159
>Why do you think there is no delay in the real part? I never said I thought there was no delay in the real part. But if you look at their datasheet 100ps doesnt relate to anything. If they want to put delays in why dont they put the actual delays from their datasheet? It is then obvious for anyone looking at a simulation what the meaning of the delay is. JonArticle: 141160
maxascent wrote:
> But if you
> look at their datasheet 100ps doesnt relate to anything.
It's a hack.
#1 in verilog.
after 0 ns in vhdl.
-- Mike Treseler
Article: 141161On Jun 9, 12:40=A0am, "david wang" <wdav...@hotmail.com> wrote: > Hi, > > I am reading the book "Digital Signal Processing with Field Programmable > Gate Arrays" 3rd. > However, the included CD-ROM and manual are missing and the linkhttp://ho= metown.aol.de/uwemeyerbaeseis not working anymore. > Anyone knows where I can download the source code/manual for this book? > > Best Regards, > > Tom or you could send him an email and ask him for help... http://www.eng.fsu.edu/faculty/index.php?id=3D1048 (I took his class at FSU)Article: 141162
On Tue, 09 Jun 2009 13:49:40 -0500, "maxascent" wrote:
>I never said I thought there was no delay in the real part. But if you
>look at their datasheet 100ps doesnt relate to anything. If they want to
>put delays in why dont they put the actual delays from their datasheet? It
>is then obvious for anyone looking at a simulation what the meaning of the
>delay is.
But that's not the way the world works. The clock-to-output delay
of a memory (or anything!) is not fixed by the thing's design;
it is affected by fanout, routing, temperature, supply voltage
and so on. Simulation models handle this by specifying a delay
in such a manner that the delay can then be patched-up ("back-
annotated") after place-and-route, using the SDF delay markup
format. Without backannotation there is no way to get the number
exactly right. So it's sensible for the model designer to put in
a vaguely reasonable standard number. Users understand that
this is just a placeholder for the P&R-specific backannotated
value, but it can still be useful as an aid to visualization
and to work around certain awkward race conditions in some
types of simulation.
Try a backannotated timing simulation (and be prepared for it
to be SLOOOOOOOW!) to see how the accurate timing numbers
get plugged in.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 141163On Jun 9, 2:49=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > >Why do you think there is no delay in the real part? =A0 > > I never said I thought there was no delay in the real part. But if you > look at their datasheet 100ps doesnt relate to anything. If they want to > put delays in why dont they put the actual delays from their datasheet? I= t > is then obvious for anyone looking at a simulation what the meaning of th= e > delay is. Others have explained why they add a nominal delay. But if you want it to correspond to something in the data sheet, what exactly? That is my point. There is no data sheet spec that would be useful to show in a pre-route simulation. But there is some value to using a small delay to showing that this is a result of the clock and not a precedent. I can see where that would be useful. Maybe I'll start adding "after 1 ns" to my designs. ;^) RickArticle: 141164
> rickman wrote: > >> Why do you think there is no delay in the real part? No matter where >> you measure it, there will be some delay. >> > True, but the exact delay is unknown until place and route. I prefer > to to leave it as a delta delay for the description and let synthesis > fill in the real value for STA or backanno. > > -- Mike Treseler > Why? What does it hurt to have a short stand-in delay in the functional simulation model. It has already been pointed out that it makes debugging a little easier, especially for the less trained. ---Matthew HicksArticle: 141165
On Jun 9, 5:42=A0pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > > rickman wrote: > > >> Why do you think there is no delay in the real part? =A0No matter wher= e > >> you measure it, there will be some delay. > > > True, but the exact delay is unknown until place and route. I prefer > > to to leave it as a delta delay for the description and let synthesis > > fill in the real value for STA or backanno. > > > -- Mike Treseler > > Why? =A0What does it hurt to have a short stand-in delay in the functiona= l > simulation model. =A0It has already been pointed out that it makes debugg= ing > a little easier, especially for the less trained. > > ---Matthew Hicks Why does it hurt? Supposing you've got a bad clocking scheme that would show a problem in unit simulation if the part was modeled like all the other behavioral code? The delay could mask a potential problem that could be a nightmare to debug in the FPGA. John ProvidenzaArticle: 141166
On Tue, 09 Jun 2009 08:00:34 -0700, Mike Treseler wrote: > maxascent wrote: >> Why dont they just let you use your own download manger? > > I got the DVD. 'free' for a $7 shipping charge. The local reps are so hungry for business that they hand delivered the DVD to our office for free. Does gloating make me a bad person? Regards, AllanArticle: 141167
On Tue, 09 Jun 2009 13:49:40 -0500, maxascent wrote: >>Why do you think there is no delay in the real part? > > I never said I thought there was no delay in the real part. But if you > look at their datasheet 100ps doesnt relate to anything. If they want to > put delays in why dont they put the actual delays from their datasheet? > It is then obvious for anyone looking at a simulation what the meaning > of the delay is. > > Jon They're adding a nominal delay. But what value should they use? If it's too small (e.g. 10 fs) it will be converted to 0 if it's less than the simulator resolution, and this may cause functional errors (as it is no longer able to work around the delta delay problem (if my understand of these delays is correct)). If it's too large (e.g. 1 ns) it will be greater than half a clock period if the clock is over 500MHz, and this may cause functional errors. Simulator resolutions are always(?) powers of ten time 1 fs. 100 ps is the only sensible delay to use for this model - it works with the largest range of simulator resolution settings while not being so large that it causes simulation errors. That it doesn't relate to any actual delay from the datasheet is irrelevant. Regards, AllanArticle: 141168
Dear All, We have implemented a high speed qpsk demodulator in a FPGA demodulator board. Until now we fed the I and Q inputs from another board by wire. Now we are looking for an IF board that can take a 70 Mhz RF signal and output the I and Q signals to be fed to our FPGA board. Can anybody recommend one? Thanx in advanceArticle: 141169
On Jun 8, 5:10=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > I have generated a memory with coregen. It has a write port clocked from > clka and a registered read port clocked from clkb. When I simulate it the > written data appears 2 clk cycles after the address changes which is what= I > expect. However there is also a 100ps delay from the clk edge to when the > data changes. So I basically have a delay of 2 clk cycles plus 100ps. Is > this an error or have I missed something? > > Cheers > > Jon Xilinx Block Memory Generator core has 2 options to generate simulation model: - a simplified Behavioral Simulation Model. This is BLK_MEM_GEN_V3_1.v file in Xilinx 11.1 installation. 100ps delay seems to be coming from "parameter flop_delay=3D100". Also, there is a timing check in RAMB.v file : "specify (CLKB =3D> DOB) =3D (100, 100);" 100ps is a safe choice because the BRAM can to run up to 450MHz, according to the datasheet. - structural simulation model, which uses primitive instantiations to model the behavior of the core more precisely. If you want to get rid of 100ps delay, try regenerating the memory in "structural simulation" mode. But the simulation time will be longer. - OutputLogicArticle: 141170
They needed to add some delay to their model as the real device has a clock to output delay of around 100ps (61ps to 82ps depending on speed grade for V5), otherwise the simulation would be wrong. I guess they decided to just use this nominal value rather than the datasheet value for simplicity. JonArticle: 141171
Hello,
I've been busy lately, trying to understand how to interface asynchronous SRAMs
(like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-II)
I have found some descriptions of multicycle methods, using FSMs, but this does
not fit my target because my circuits already run at "nominal speed" (8 to 15ns
cycles, depending on the SRAM chip). So I attempt to find how SRAM reads and
writes can be done in one cycle, with a FPGA that can't (or shouldn't) go faster.
(Yes I use Actel's ProASIC and I'm fine).
I have found (through the examination of timing diagrams in several datasheets)
that I can design a stateless async SRAM interface with this behaviour :
Read :
on clock's rising edge :
latch the address bus's value,
Output Enable = 1, WriteEnable = 1,
and keep data bus floating
after 1/3 of clock cycle :
Output Enable = 0
on next clock rising edge :
latch the data bus input.
Write :
on clock rising edge :
latch addres bus, OE=1, WriteEnable=1,
keep data bus floating
after 1/3 of clock cycle :
WriteEnable = 0
after 1/2 clock cycle (falling edge)
latch data output and drive the output buffer
It's fine for me because it can be done by
correctly wiring latches to the proper control/data/clock signals
and it should work. Now comes the big question :
How would I generate the 1/3 clock cycle signal ?
* I don't want to use a 3x clock because the design already
fast and even though the PLL can output 350MHz, I'm not sure
that the logic and routing will follow (so making a 3-state FSM
is eventually possible but not realistic, too uncertain).
A dual-edged FSM with 1,5x clock would be another improbable chimera...
* I have seen that the PLL can generate a 5ns (max) delayed clock
based on the main clock, so it's fine for 15ns-rated SRAMs
(I could set the delay to 2,6ns for 8ns parts)
but what happens if 20ns or slower SRAMs are to be used ?
(I have 70ns chips for example, but I don't want to make
a FSM just for a few slow parts)
Also, I would like to keep/reserve PLL outputs for other purposes.
* In all the datasheets I have found, it is implicitly
necessary to have this 1/3 delay :
- if shorter, there is a driver conflict on the data bus
if the precendent cycle was a read
(data remain present up to about 1/3 of the next clock cycle)
- if longer, the data setup time is not respected and reliability suffers.
Any idea ?
And are my assumption valid ?
(for those who have already designed this kind of circuitry)
yg
--
http://ygdes.com / http://yasep.org
Article: 141172On Jun 10, 2:01=A0pm, whygee <why...@yg.yg> wrote: > Hello, > > I've been busy lately, trying to understand how to interface asynchronous= SRAMs > (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-II= ) > > I have found some descriptions of multicycle methods, using FSMs, but thi= s does > not fit my target because my circuits already run at "nominal speed" (8 t= o 15ns > cycles, depending on the SRAM chip). So I attempt to find how SRAM reads = and > writes can be done in one cycle, with a FPGA that can't (or shouldn't) go= faster. > (Yes I use Actel's ProASIC and I'm fine). > > I have found (through the examination of timing diagrams in several datas= heets) > that I can design a stateless async SRAM interface with this behaviour : > > Read : > =A0 on clock's rising edge : > =A0 =A0 =A0latch the address bus's value, > =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1, > =A0 =A0 =A0and keep data bus floating > =A0 after 1/3 of clock cycle : > =A0 =A0 =A0Output Enable =3D 0 > =A0 on next clock rising edge : > =A0 =A0 =A0latch the data bus input. > > Write : > =A0 =A0on clock rising edge : > =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1, > =A0 =A0 =A0keep data bus floating > =A0 =A0after 1/3 of clock cycle : > =A0 =A0 =A0 WriteEnable =3D 0 > =A0 =A0after 1/2 clock cycle (falling edge) > =A0 =A0 =A0 latch data output and drive the output buffer > > It's fine for me because it can be done by > correctly wiring latches to the proper control/data/clock signals > and it should work. Now comes the big question : > > How would I generate the 1/3 clock cycle signal ? > > * I don't want to use a 3x clock because the design already > fast and even though the PLL can output 350MHz, I'm not sure > that the logic and routing will follow (so making a 3-state FSM > is eventually possible but not realistic, too uncertain). > A dual-edged FSM with 1,5x clock would be another improbable chimera... > > * I have seen that the PLL can generate a 5ns (max) delayed clock > based on the main clock, so it's fine for 15ns-rated SRAMs > (I could set the delay to 2,6ns for 8ns parts) > but what happens if 20ns or slower SRAMs are to be used ? > (I have 70ns chips for example, but I don't want to make > a FSM just for a few slow parts) > Also, I would like to keep/reserve PLL outputs for other purposes. > > * In all the datasheets I have found, it is implicitly > necessary to have this 1/3 delay : > =A0 =A0- if shorter, there is a driver conflict on the data bus > =A0 =A0 =A0 if the precendent cycle was a read > =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock cyc= le) > =A0 =A0- if longer, the data setup time is not respected and reliability = suffers. > > Any idea ? > And are my assumption valid ? > (for those who have already designed this kind of circuitry) > > yg > --http://ygdes.com/http://yasep.org if you as ram is specified as 15ns type then do not hope it attaches to soc system with 15ns cycle time AnttiArticle: 141173
On Jun 10, 1:29=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Jun 10, 2:01=A0pm, whygee <why...@yg.yg> wrote: > > > > > > > Hello, > > > I've been busy lately, trying to understand how to interface asynchrono= us SRAMs > > (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-= II) > > > I have found some descriptions of multicycle methods, using FSMs, but t= his does > > not fit my target because my circuits already run at "nominal speed" (8= to 15ns > > cycles, depending on the SRAM chip). So I attempt to find how SRAM read= s and > > writes can be done in one cycle, with a FPGA that can't (or shouldn't) = go faster. > > (Yes I use Actel's ProASIC and I'm fine). > > > I have found (through the examination of timing diagrams in several dat= asheets) > > that I can design a stateless async SRAM interface with this behaviour = : > > > Read : > > =A0 on clock's rising edge : > > =A0 =A0 =A0latch the address bus's value, > > =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1, > > =A0 =A0 =A0and keep data bus floating > > =A0 after 1/3 of clock cycle : > > =A0 =A0 =A0Output Enable =3D 0 > > =A0 on next clock rising edge : > > =A0 =A0 =A0latch the data bus input. > > > Write : > > =A0 =A0on clock rising edge : > > =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1, > > =A0 =A0 =A0keep data bus floating > > =A0 =A0after 1/3 of clock cycle : > > =A0 =A0 =A0 WriteEnable =3D 0 > > =A0 =A0after 1/2 clock cycle (falling edge) > > =A0 =A0 =A0 latch data output and drive the output buffer > > > It's fine for me because it can be done by > > correctly wiring latches to the proper control/data/clock signals > > and it should work. Now comes the big question : > > > How would I generate the 1/3 clock cycle signal ? > > > * I don't want to use a 3x clock because the design already > > fast and even though the PLL can output 350MHz, I'm not sure > > that the logic and routing will follow (so making a 3-state FSM > > is eventually possible but not realistic, too uncertain). > > A dual-edged FSM with 1,5x clock would be another improbable chimera... > > > * I have seen that the PLL can generate a 5ns (max) delayed clock > > based on the main clock, so it's fine for 15ns-rated SRAMs > > (I could set the delay to 2,6ns for 8ns parts) > > but what happens if 20ns or slower SRAMs are to be used ? > > (I have 70ns chips for example, but I don't want to make > > a FSM just for a few slow parts) > > Also, I would like to keep/reserve PLL outputs for other purposes. > > > * In all the datasheets I have found, it is implicitly > > necessary to have this 1/3 delay : > > =A0 =A0- if shorter, there is a driver conflict on the data bus > > =A0 =A0 =A0 if the precendent cycle was a read > > =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock c= ycle) > > =A0 =A0- if longer, the data setup time is not respected and reliabilit= y suffers. > > > Any idea ? > > And are my assumption valid ? > > (for those who have already designed this kind of circuitry) > > > yg > > --http://ygdes.com/http://yasep.org > > if you as ram is specified as 15ns type > then do not hope it attaches to soc system with 15ns cycle time > > Antti- Hide quoted text - > > - Show quoted text - Paying attention to the r/w line and that it can be raised at the end of a cycle not just after 70% of the cycle, and realizing this is the main issue for meeting the cycle time constraints. Keeping /OE low for read and write (as r/w overides the output buffer, check the specs). Raising r/w early is no problem as data the same, lowering it early maybe is what you need? The drive shorting rail to rail would be a power loss issue so maybe delay the data output of the processor slighly... the rising edge will be countered by the addressing delay. The timing may be very possible if you do interleave every write with a read, but as I said the timing will be tight.Article: 141174
On Jun 10, 11:44=A0am, recoder <kurtulmeh...@gmail.com> wrote: > Dear All, > =A0We have implemented a high speed qpsk demodulator in a FPGA > demodulator board. > Until now we fed the I and Q inputs from another board by wire. > Now we are looking for an IF board that can take a 70 Mhz RF signal > and output the I and Q signals to be fed to our FPGA board. > Can anybody recommend one? > Thanx in advance Have you looked at Sundance boards? I did not try them yet but I found them when looking for the same thing. It will not be cheap but it's on the shelf (let's hope). Regards, Moti
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