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
Kevin, I wouldn't mind simulating in VHDL, but the Xilinx tool won't let me setup any of the "create simulation model" processes to output VHDL. I only get a variety of verilog flavors to choose from. (My source files are verilog.) Do you know a different way?Article: 80576
valentin tihomirov wrote:
> I wonder how you can so easily speak about adding regisers somewhere in the
> circuit.
It's more a question of where do you
want to draw the boxes for a multi-module
design. With no rules at all you will have
a random collection of interfaces at
the ports:
<><>out]--[in<><>
1. reg to reg
2. flop to flop
3. reg to flop
4. flop to reg
1. Complicates timing.
2. Wastes flops
3. Is backwards from hdl synthesis
which assumes but does not enforce
synchronous inputs and creates registered
outputs.
So I say type 4 only:
All modules have plain inputs
and registered outs.
> Wouldn't it change the functionality of the circuit (missing
> cycles)? Consider a MUX(S, A, B): you cannot just FF the outputs as this
> will break the contract inferring a cycle delay.
Yes. Registering an output involves a one tick delay.
Consider simulation to get each module lined up right.
-- Mike Treseler
Article: 80577Mike Treseler wrote: > Jason Zheng wrote: > >> 3%? I wonder how you implemented your 1-hot state machine. > > > By changing a synthesis option setting. > The state type is just an enumeration. See: > http://home.comcast.net/~mike_treseler/uart.vhd > -- Mike Treseler I'm not a VHDL coder but I read your code and have a feeling that your VHDL code did not synthesize to an optimal one-hot state machine. In verilog, there's a synthesis directive called "full-case" which tells the synthesizer that all the cases are covered and it doesn't need to generate the default case, which can kill 1-hot performance.Article: 80578
Peter Sommerfeld wrote: > Great, thanks for the link. They're results are that the sync and async > versions of the same processor have the same area, speed, and power > consumption except that the async version apparently has less EMI. I > was hoping the async design would have advantages in other areas, but I > guess not. This was done using FPGA tool flows, designed for Sync use, and also speed files done the same way - So I would not read too much into the area and speed comparisons. I'm impressed they got it to go thru the tools at all :) Keeping the async handshakes safe is likely to consume area, but you could expect to save on less beefy global glock trees and drivers. The benefits I expect Epson see from Async, are more in deployment than area or speed - if they can save hot spots, eliminate regulators, and spread the EMI, as well as extend battery life, those are all important gains to make in portable consumer equipment. -jgArticle: 80579
valentin tihomirov wrote:
> I wonder how you can so easily speak about adding regisers somewhere in the
> circuit.
(corrected reply)
It's more a question of where do you
want to draw the boxes for a multi-module
design. With no rules at all you will have
a random collection of interfaces at
the ports:
<><>out]--[in<><>
1. gate to gate
2. reg to reg
3. gate to reg
4. reg to gate
1. Complicates timing.
2. Wastes regs
3. Is backwards from hdl synthesis
which assumes but does not enforce
synchronous inputs and creates registered
outputs.
So I like type 4 only:
All modules have plain inputs
and registered outs.
> Wouldn't it change the functionality of the circuit (missing
> cycles)? Consider a MUX(S, A, B): you cannot
> just FF the outputs as this
> will break the contract inferring a cycle delay.
Yes. Registering an output involves a one tick delay.
Consider simulation to get each module lined up right.
-- Mike Treseler
Article: 80580OK, I found the documentation on NetGen. I'll give it a try. Thanks everyone for responding.Article: 80581
Yet another async FIFO question... :( I've inherited an async FIFO that doesn't work. This is, I think, a fairly standard implementation. On the write port, a clock and a write enable increment a write pointer, and write the write data into a RAM. The read pointer is Gray-coded, clocked into a reg on the write clock, inverse coded, and then compared with the write pointer, to give a write-side full flag. The read side is simply the inverse of the write side. So far, so good. The problem is that this design assumes a free-running write clock, and my write clock is not free-running; I simply generate a clock when the (unpredicatable) write data appears. The write enable is therefore effectively redundant. The problem arises because the 'fifo full' flag is generated by the *write* clock. If, on write X, the comparator determines that the FIFO is full, then the full flag is generated, and I don't create any more write clocks. The read side might empty the FIFO, but this information never gets back to the write port, because the register that samples the Gray-coded read pointer is clocked by the write clock. Any ideas on how I re-design this to cope with a write clock which isn't free-running? TIA - PaulArticle: 80582
Hi there, Please excuse my quite probably lame, simple question but I've been searching on the net for a while and haven't really answered myself yet! I'm not at all used to programming fpga's, as my work has only ever been with ASICs, and on a customer level. Now I've aquired some small 15k fpga's (XC2S15's) to put small state machines in, however I'm not entirely sure how to hold my bitstream. Now the official flash prom's seem very expensive to me (at least at my supplier). I read the xapp079 app note and realise I could use a parallel eeprom. Now, could I use something like the AT29 flash PEROM from Atmel for this? Can I program it using the download cable - it doesn't seem to have a JTAG, so I don't get how to do this without a seperate programmer for the device. Would someone mind just walking me through my options like I'm a baby!? I'm a hobbiest, so I really want to do it on the cheap and don't want to buy any tools etc. Many thanks, Andy Main.Article: 80583
"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message news:1110304872.233206.130150@z14g2000cwz.googlegroups.com... <snip> > how hard is it to put a 2A supply on the board? > > Regards, > > Paul The issue of startup current surge problems has been addressed on this newsgroup before with battery-operated designs stresing seriously to supply the startup surge. Chips without inrush are so much nicer to work with. If it's a non-problem, why would Altera bother to state on http://www.altera.com/products/devices/stratix2/features/st2-competitive.html that "Because Virtex-4 power-up specifications are higher than its static current, it draws in-rush current spike during power-up" and show an inrush spike in the graph if there is no inrush in Virtex-4 devices just as there is no inrush in the other Stratix-II devices? Scope traces sure would be nice for *that* graph. There are designers that need well behaved chips because they don't have the luxury of wired supplies and those engineers that have been bitten by the problems in past designs will look for the issue even if it doesn't matter as much to their current designs.Article: 80584
Hi,
After I builded my design in EDK and made a toplevel VHDL in ISE, I started
writing code for both PPC on my V2P20 ... the first PPC serves as an
Communication unit which transfers data in between memories, accessible by
external device ... I have no problem whatsoever accessing these memories,
either on opb or plb busses
When I started the part of interconnecting the two PPC with a BRAM memory
using DSOCM I encountered the following problem, which up to know I cannot
solve (this is the first time I design on FPGA) ...
To access the BRAM from the first PPC serving as Comm Unit I used the code
which worked for accessing memories on the PLB since I suppose the
addressing of memories is always in the same way, as if we address one big
memory
code :
Xuint32 * bram_Ptr = XPAR_BRAM_BASE_ADDR;
Xuint32 value = *bream_Ptr;
When I download the bit file on the FPGA, the system hangs, when executing
these commands
can someone help me with this problem, I spend some time looking for the
solution and I found some macros in xio.h, but I have no clue how to use
them, and when I look into application notes, it appears nothing is ever
said about how accessing BRAM, so it must be straightforward
thx in advance
could be I miss some parameters or connections in the MHS file, but I doubt
it since all should almost be set by default
BEGIN dsocm_v10
<--- connected to the PPC405 through bus interface
PARAMETER INSTANCE = dsocm_v10_0
PARAMETER HW_VER = 2.00.a
PARAMETER C_DSCNTLVALUE = 0x85
PORT DSOCM_Clk = sys_clk
PORT sys_rst = sys_rst_l
END
BEGIN dsbram_if_cntlr
PARAMETER INSTANCE = dsbram_if_cntlr_0
PARAMETER HW_VER = 3.00.a
PARAMETER C_BASEADDR = 0xF0000000
PARAMETER C_HIGHADDR = 0xF0001fff
BUS_INTERFACE DSOCM = dsocm_v10_0
BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
END
BEGIN bram_block
PARAMETER INSTANCE = bram_block_0
PARAMETER HW_VER = 1.00.a
BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
BUS_INTERFACE PORTB = dsbram_if_cntlr_1_porta
END
could be I made some mistake in my linker script :
_STACK_SIZE = 1k;
_DOCM_SIZE = 8k;
MEMORY
{
plb_bram_if_cntlr_1_bram : ORIGIN = 0xFFFF0000, LENGTH = 16K
plb_bram_if_cntlr_2_bram : ORIGIN = 0xFFFF8000, LENGTH = 32K
dsbram_if_cntlr_0_porta : ORIGIN = 0xF0000000, LENGTH = 8K
}
...
Article: 80585Hi John, > The issue of startup current surge problems has been addressed on this > newsgroup before with battery-operated designs stresing seriously to supply > the startup surge. Chips without inrush are so much nicer to work with. I agree -- better not to have in-rush. But for most applications of high-end FPGAs (few of which are battery operated), working around an in-rush spike is not a big deal. And I should point out that if you are using a 2S60ES to actually do something, you're likely using something 2A+ for static + dynamic anyway. > If it's a non-problem, why would Altera bother to state on > > http://www.altera.com/products/devices/stratix2/features/st2-competitive.html > > that "Because Virtex-4 power-up specifications are higher than its static > current, it draws in-rush current spike during power-up" and show an inrush > spike in the graph if there is no inrush in Virtex-4 devices just as there > is no inrush in the other Stratix-II devices? Scope traces sure would be > nice for *that* graph. The V-4 plot is based on Xilinx's spec. See "Virtex-4 Data Sheet: DC and Switching Characteristics" Table 5 and compare to Table 4. For the LX60, "Typical" (nominal Si, 25C) leakage is 167 mA on IccInt while "typical" power-on current is 303 mA for IccInt. For IccAux, the numbers are 74 mA and 222 mA respectively. I do not have a scope shot, but I trust they had good reason to publish their specs. Even if I measured a chip, there is no guarentee that unit I measured would be at the "typical" point as far as start-up vs. leakage is concerned. Whenever Xilinx gets around to publishing worst-case specs, it would be even more meaningless for me (or you) to try to capture the spec'ed behaviour on a scope, given that you are very unlikely to have a worst-case unit in your hands. So V4 has a power-up surge. Does this mean V4 is a bad or "broken" chip? No -- at least, as far as I can tell without a published worst-case spec. Oh yeah, and the spec given is only valid if VccAux ramps before VccO (paragraph 2, page 5 of datasheet)... so I don't know what happens in arbitrary ordering, for example when you want to be hot-socket compliant. Our point in showing this graph is that the power-on surge really doesn't matter much anyway since operating power requirements dominate. This was in response to some Xilinx FUD where they treated our previously published instantaneous current spec as if it was a "power" consumption (only valid for a constant current draw), whereas for most applications you really only care about operating power. All that graph is meant to show is that (a) Stratix II has no power-on surge and (b) even for a chip (V4) that has one, it probably isn't a dominant effect. Regards, Paul Leventis Altera Corp.Article: 80586
Hi Jock, > For the Xilinx we used the .rbt file which is an ASCII version of the .bit > file. > > Does anyone know what the Altera equivalent of the .rbt file is? That would be the .ttf file. You can find it under Assignments->Device->Device and pin options->Programming files. Best regards, BenArticle: 80587
Hi - What's clocking the logic that's looking at the full flag? Is it by any chance an ungated version of the write clock? Bob Perlman Cambrian Design Works On Tue, 08 Mar 2005 19:04:09 +0000, Paul Davis <rft56@dsl.nospam.pipex.com> wrote: >Yet another async FIFO question... :( > >I've inherited an async FIFO that doesn't work. This is, I think, a >fairly standard implementation. On the write port, a clock and a write >enable increment a write pointer, and write the write data into a RAM. > >The read pointer is Gray-coded, clocked into a reg on the write clock, >inverse coded, and then compared with the write pointer, to give a >write-side full flag. > >The read side is simply the inverse of the write side. > >So far, so good. The problem is that this design assumes a >free-running write clock, and my write clock is not free-running; I >simply generate a clock when the (unpredicatable) write data appears. >The write enable is therefore effectively redundant. > >The problem arises because the 'fifo full' flag is generated by the >*write* clock. If, on write X, the comparator determines that the FIFO >is full, then the full flag is generated, and I don't create any more >write clocks. The read side might empty the FIFO, but this information >never gets back to the write port, because the register that samples >the Gray-coded read pointer is clocked by the write clock. > >Any ideas on how I re-design this to cope with a write clock which >isn't free-running? > >TIA - > >PaulArticle: 80588
This might be very tricky. That's why I always demand free-running
clocks.
FULL gets set by the write clock, which is ideal, since only the write
side is interested in FULL.
But FULL gets reset by a write clock, and that is inherently
asynchronous to any write operation. So one has to do some trickery to
move the falling edge of FULL back to the write clock domain. That's
where metastability can bite you.
And the same is also true for EMPTY ( with the clock names reversed).
The extra delay encountered at the trailing edge of FULL ( or EMPTY)
really does not matter, as long as it's just a few clock ticks. It just
means the FIFO pretends to be FULL (or EMPTY) a few cycles longer than
necessary. No big deal.
Maybe this helps to get your creative juices flowing. Your challenge is
non-trivial.
Peter Alfke, Xilinx Applications ("FIFO is my middle name")
Article: 80589On Tue, 08 Mar 2005 20:47:29 GMT, Bob Perlman <bobsrefusebin@hotmail.com> wrote: >Hi - > >What's clocking the logic that's looking at the full flag? Is it by >any chance an ungated version of the write clock? No - it's just the write clock that gets supplied to the FIFO. I do create the clock myself, though - it's a combination of various signals from two other clock domains. There isn't a free-running precursor to this signal in one of the two domains (presumably that's what you meant?) - PaulArticle: 80590
Paul Davis wrote: > Yet another async FIFO question... :( > > I've inherited an async FIFO that doesn't work. This is, I think, a > fairly standard implementation. On the write port, a clock and a write > enable increment a write pointer, and write the write data into a RAM. > > The read pointer is Gray-coded, clocked into a reg on the write clock, > inverse coded, and then compared with the write pointer, to give a > write-side full flag. > > The read side is simply the inverse of the write side. > > So far, so good. The problem is that this design assumes a > free-running write clock, and my write clock is not free-running; I > simply generate a clock when the (unpredicatable) write data appears. > The write enable is therefore effectively redundant. > > The problem arises because the 'fifo full' flag is generated by the > *write* clock. If, on write X, the comparator determines that the FIFO > is full, then the full flag is generated, and I don't create any more > write clocks. The read side might empty the FIFO, but this information > never gets back to the write port, because the register that samples > the Gray-coded read pointer is clocked by the write clock. > > Any ideas on how I re-design this to cope with a write clock which > isn't free-running? > > TIA - > > Paul I think it was common back in the day to have FIFOs without free-running clocks but these have mostly disappeared. What you really want to do, if at all possible, is to make the write clock free-running and gate it with the write enable. If you have a gated write clock, you introduce a lot of timing issues, and the whole point of the asynchronous FIFO is to encapsulate the domain-crossings and abstract those problems away from you. You can change the full flag so that it is clocked by the read domain, but then, again, you are reading it in a different domain and have domain-crossing issues. You want all of the domain crossings to be between the gray-coded pointers inside the FIFO. -KevinArticle: 80591
Andy Main wrote: > Hi there, > > Please excuse my quite probably lame, simple question but I've been > searching on the net for a while and haven't really answered myself yet! > > I'm not at all used to programming fpga's, as my work has only ever been > with ASICs, and on a customer level. Now I've aquired some small 15k > fpga's (XC2S15's) to put small state machines in, however I'm not > entirely sure how to hold my bitstream. Now the official flash prom's > seem very expensive to me (at least at my supplier). I read the xapp079 > app note and realise I could use a parallel eeprom. Now, could I use > something like the AT29 flash PEROM from Atmel for this? Can I program > it using the download cable - it doesn't seem to have a JTAG, so I don't > get how to do this without a seperate programmer for the device. I looked on the web for XCF01SVO20C and got a web price of $3.15 If this is expensive to you, I don't see what you're going to do with the AT29 flash. This is a 1Mbit part big enough to program about 5 of your XC2S15's if you chain them. It has JTAG and works with the Xilinx iMPACT software. Good luck doing better with less effort. > > Would someone mind just walking me through my options like I'm a baby!? > I'm a hobbiest, so I really want to do it on the cheap and don't want to > buy any tools etc. > > Many thanks, > > Andy Main.Article: 80592
On 8 Mar 2005 13:36:30 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >Maybe this helps to get your creative juices flowing. Your challenge is >non-trivial. No kidding... :) Luckily, I'm on an hourly rate. Just checking that there weren't any simple answers. I recall using small discrete FIFOs about 10 or 15 years ago that bubbled through read and write ops, and that only required a single write strobe. I may try to look it up (a 7400 device?), but I remember being surprised that they worked at all. - PaulArticle: 80593
I'm trying to use a Xilinx XC2VP20 (Virtex II Pro family) to prototype an ASIC device but I'm experiencing a lot of trouble cause i'm new to FPGA. The problem is that my project has various asyncronous clocks generated internally by means of dividers and NCOs. I would like to route these clocks through low skew lines by instantiating BUFG blocks (I've read on the Virtex II Pro user guide that it is possible) but even if XST compiles without errors ISE is not able to translate the design. Does anyone knows if I'm trying the impossible or has any suggestion? Any help will be strongly appreciated...Article: 80594
Paul Taddonio wrote: >We have a tight schedule so I will stick with the familiar language. >Any suggestions would be appreciated. Going from Verilog to VHDL isn't as big a headache as you think. Go to http://www.confluent.org/wiki/doku.php and click on HDL comparison to get a quick guide on the differences in Confluence, Verilog and VHDL.Article: 80595
Hello, all, I am working on an update for a board that now uses an original 5-V Spartan (XCS30) part. To reduce cost, I'm looking at using the Spartan II XC2S30 part, which is less than half the price. (I'd go with the Spartan IIE, but the smallest is 50K gates, and config bitstream is about double the 2S30's requirement, which negates the price advantage.) Anyway, there are some 512KBit serial PROMs available from some other makers that are 1/10th the cost of the Xilinx parts. But, they max out at 400 Kbits/second, and the SpartanII starts configuring at 2.5 MBits /second in master serial mode. I think I have come up with a very simple circuit to divide my system clock down and sync INIT/ to it, so that I can run the SpartanII in slave serial mode with a clock rate appropriate for the slow SPROM. I think I can do it in 2 74HCxx packages. Does anyone have any comments on this? Have you done something similar? (This particular product has no CPU onboard. I suppose I could come up with a way to configure the FPGA from a host CPU, but there are a few reasons I might want to avoid that.) Thanks, JonArticle: 80596
Hi, Check the availability of BUFG's in your device(do you exceed?). There are some other options like taking the clk to I/O pin and bringing back the clk and using a DLL to adjust the skew as required(which is best option i think, with assumption that you have spare I/O pins and DLL's available in your device). Thanks raoArticle: 80597
> I looked on the web for XCF01SVO20C and got a web price of $3.15 > If this is expensive to you, I don't see what you're going to do with > the AT29 flash. This is a 1Mbit part big enough to program about 5 > of your XC2S15's if you chain them. It has JTAG and works with the > Xilinx iMPACT software. Good luck doing better with less effort. Much better, though I can't find any in the UK (RS/Farnell) - only the huge Virtex proms that made me think all this in the fist place. If anybody knows a suitable supplier for low quantity purchases please let me know. I'd be very grateful. Andy.Article: 80598
Hi, I was able to make Xilinx Edition ModelSim(free) work both for verilog and vhdl. Follow the below procedure. What you can do is first install vhdl version, then copy vhdl folder from C:\Modeltech_xe_starter\xilinx\vhdl to different location. Then uninstall the modelsim and again install this time for verilog, this time you have C:\Modeltech_xe_starter\xilinx\verilog Now copy the vhdl from previous location to this location C:\Modeltech_xe_starter\xilinx\ If you now open the modelsim you have both libraries. Thanks raoArticle: 80599
Call for Papers
2005 MAPLD International Conference
Ronald Reagan Building and International Trade Center
Washington, D.C.
September 7-9, 2005
The 8th annual MAPLD International Conference will present papers on
programmable logic devices and technologies, digital engineering, and
related fields, for military and aerospace applications. Devices,
technologies, logic design, verification, flight applications, fault
tolerance, reliability, radiation susceptibility, and encryption
applications of programmable devices, processors, and adaptive
computing systems in military and aerospace systems are topics for
papers.
For 2005, MAPLD will be expanded to 3 full days and will feature
expanded "Birds of a Feather" Workshop Sessions. Full-day seminars
will be offered on September 6, 2005.
We are planning an exciting program with presentations by Government,
industry, academia, and consultants, including talks by distinguished
Invited Speakers. This conference is open to US and foreign
participation and is unclassified. For related information, please
see the NASA Office of Logic Design Web Site (http://klabs.org).
Abstract submittal info: http://klabs.org/mapld05/
Abstract deadline: April 25, 2005
Special Talks Include (developing):
* Welcome and Opening Address
Ralph Roe, NASA Engineering and Safety Center
* Invited Mishap Talk (new for 2005)
"Computer Overload and The Apollo 11 Lunar Landing"
Jack Garman (formerly NASA JSC)
* Panel Session: "Why Are Space Stations So Hard?"
Roger Launius, National Air and Space Museum
Keith Cowing, Editor, NASA Watch
and more ....
* Invited History Talk
* The Application Engineers' View
Four Seminars Are Being Planned:
* Design Integrity
* Device Failure Modes and Reliability
* Reconfigurable High-Performance Computing
* Real-Time, Hi-Rel Software Issues for Computer Designers
Planned Technical Sessions
* Applications: Military & Aerospace
* Verification of High Reliability Designs
* Radiation Effects and Mitigation Techniques
* Logic Design and Processors
* Reconfigurable Computing, Evolvable Hardware, and Security
* Poster Session
* BOF-L: Mitigation Methods for Reprogrammable Logic in the Space
Radiation Environment
* BOF-F: Reconfigurable Computing
* BOF-J: PLD Failures, Analyses, and the Impact on Systems
* BOF-S: NESC and Software
* BOF-G: Digital Engineering and Computer Design - A Retrospective
and Lessons Learned for Today's Engineers
* BOF-W: Verification of Large Designs and Related Design
Methodologies
Reservations are being accepts for the Industrial & Gov't Exhibits:
http://klabs.org/mapld05/exhibits/reservation_request_form.htm
Early Industrial and Governemnt participants include:
NASA Office of Logic Design Synthworks
Space Micro SRC Computers
BAE Systems: Information and Aldec
Electronic Warfare Systems
Actel Corporation ATK Mission Research Corporation
Aeroflex Colorado Springs Xilinx, Inc.
Sigrity Mentor Graphics Corporation
IEEE Aerospace and Electronics NASA Engineering and Safety Center
Systems Society
Nallatech Celoxica
Northrop Grumman Corporation SEAKR Engineering
For additional information:
Conference home page: http://klabs.org/mapld05
Richard B. Katz
NASA Office of Logic Design
mapld2005@klabs.org
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