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
Hi I was hoping to get some opinions on Lattice FPGAs compared to Xilinx and Altera. I see they have a SC device out. How does this compare to similar devices from the other two? Cheers JonArticle: 99276
You are using Virtez-2Pro CoreGen. Simultaneous read/write operations on the dual-ported Block-RAM are no problem whatsoever. Peter Alfke, Xilinx ApplicationsArticle: 99277
Hi all,
i am not sure whether i can post this message ,because this is
regarding synopsys design compiler.After running the compiler for 4
hours(it is reasonably big circuit) ,it is giving the error
memory structure is not intact
/opt3/synopsys/v-2003.12-sp1/pce/sparcoS5/syn/bin//design_analyzer:
line 10: 32
50 Segmentation Fault (core dumped) ${exec_name} -r
${synopsys_root} "$@"
does anyone have any idea over these kind of errors
thanks for all your help provided so far,
Regards
Ramakrishna Bachimanchi
Article: 99278
Hi all,
in the previous message i mentioned it as design compiler, but actually
it is design analyzer.
i am not sure whether i can post this message ,because this is
regarding synopsys design analyzer.After running the design analyzer
for 4
hours(it is reasonably big circuit) ,it is giving the error
memory structure is not intact
/opt3/synopsys/v-2003.12-sp1/pce/sparcoS5/syn/bin//design_analyzer:
line 10: 32
50 Segmentation Fault (core dumped) ${exec_name} -r
${synopsys_root} "$@"
does anyone have any idea over these kind of errors
thanks for all your help provided so far,
Regards
Ramakrishna Bachimanch
Article: 99279Hi Robin, It is not the one Brannon mentioned. The paper you list was published in 1997. WengArticle: 99280
It's been a while since I used eps, but I seem to remember, you can insert a line at the header of the ps file with a bounding box in it, and then remove the %showpage from the bottom of the file (assuming its there). Something like %!PS-Adobe-2.0 EPSF-2.0 %%BoundingBox: 50 50 410 302 %%EndComments The dimensions in the box size statement are in 1/72ths of an inch. Hope this helps. Phil santhosh_h_98@yahoo.com wrote: > Thanks for the answer. This works but this has a big problem. > Even if I have 2 AND gates in a design, when I export this as .eps > file, using the method you mentioned, and insert in LATEX it takes one > complete page. > > How can I copy just the part of the drawing as an .eps file ??? > > Please help. > Sant >Article: 99281
The length of the mantissa determines the resolution or precision. The exponent determines the dynamic range. Peter Alfke,Article: 99282
OK, I surrender ! Any idea how I can clear those yellow markers that result from clicking on an error message, apart from saving and reopening ? DaveArticle: 99283
Got a DCM (spartan3), CLK1X coming CLK90 pin, thru a BUFG (to get 90deg out of phase from the incoming clk) CLK2X coming from CLK2X180 pin, thru a BUFG (to get rising edge in phase with CLK1X) How safe is it to sample a signal coming from the CLK1X domain, into the CLK2X domain (and maybe back)? Does this create a race condition or will this always be safe? (I know it isnt when using modelsim, but when implementing?) I have problems matching simulation result with real life.Article: 99284
Jdon wrote: > Thanks. > > But the problem of the asynch-FIFO 16 is that > I couldn't prevent simultaneous read and write. > When the process tries to read and write at the same time by chance, > the output is distorted. It is not clear to me why you think simultaneous read/write of the FIFO doesn't work. On the other hand, since you were talking about making your own buffer with a BRAM, that can be fairly easy to do when the clock rates of the input and output are fixed. When the output clock is significantly faster than the input clock, I would normally take the least significant bit of input address, run it through a couple of synchronizer FFs at the output clock rate, and use transitions of it to generate an address. That address will follow slightly the input address, and will tell you where in the BRAM there is valid data. Care must be taken that the two addresses are started cleanly for this to work. And if there is a need to reset the buffer during operation, that also must be handled carefully. If those conditions are difficult to meet, it might be desirable to use a true asynchronous FIFO.Article: 99285
Rather than relying on perfect alignment (and risking race conditions if it is not met), I would deliberately offset the two clock domains. Obviously, this lowers the max frequency of operation, but it really makes things safe, if you have the timing margin. Peter Alfke, Xilinx ApplicationsArticle: 99286
I found the correct paper: http://scholar.google.com/url?sa=U&q=http://www.cp.eng.chula.ac.th/~krerk/publication/iscit-sqrt.pdf Entitled "an FPGA implementation of a fixed-point square root operation". Of course it works for floating point too; you just run it on the mantissa.Article: 99287
There are no Xilinx tools that would take advantage of such hardware. I suggest you spend your money on a faster chip with more cache rather than more CPUs.Article: 99288
CoreGen assumes that the read and write clock (can be totally asynchronous) are free-running, and you control the writing and reading with the Enable signals. It also assumes that you stop writing when Full and stop reading when empty. If that does not work for you, you have done something wrong. Check your design. Peter AlfkeArticle: 99289
maxascent wrote: > Hi > > I was hoping to get some opinions on Lattice FPGAs compared to Xilinx and > Altera. I see they have a SC device out. How does this compare to similar > devices from the other two? > > Cheers > > Jon The SC series is brand new so you might not find anyone with a socket on their board just yet. It *looks* like a nice family. 3+ Gbit transsceivers. 90 nm. Many 18kb mems. Oh - no "DSP" units in the SC family if I recall correctly - they put those in the "volume" parts instead: the ECP2 family. I like what I see. If you have high volume needs and want some hard IP on your board, you can get their MACO blocks wired up as a teeny asic in your FPGA.Article: 99290
Morten Leikvoll wrote: > Got a DCM (spartan3), > CLK1X coming CLK90 pin, thru a BUFG (to get 90deg out of phase from the > incoming clk) > CLK2X coming from CLK2X180 pin, thru a BUFG (to get rising edge in phase > with CLK1X) > > How safe is it to sample a signal coming from the CLK1X domain, into the > CLK2X domain (and maybe back)? > Does this create a race condition or will this always be safe? (I know it > isnt when using modelsim, but when implementing?) > I have problems matching simulation result with real life. My understanding was that with an appropriate input clock JITTER constraint given to the Xilinx tools, the timing between the two domains would be guaranteed. I've maintained the asynchronous handshakes across the odd domains (such as 2x to 3x domains) when I cross the 1X and 2X for safety so I haven't had a chance to find out first hand whether the tools deliver the real deal now that they have hold time analysis internal to the device.Article: 99291
I'm upgrading to ISE8.1 from ISE6.2 and my (old) Modelsim V5.5
is unhappy about some Verilog code in the Xilinx RAM16_S9.V
model (as well as some other of the RAM16 models).
The Xilinx model has two models built into it - a "legacy_model"
and a new model. A `ifdef selects between them. In the newer model,
there's some code that looks like:
reg [7:0] mem[2047:0];
for (count = 0; count < 32; count = count + 1) begin
mem[count] = INIT_00[(count * 8) +: 8];
mem[32 * 1 + count] = INIT_01[(count * 8) +: 8];
// more lines like the above.
This is code straight from the Xilinx unisims directory.
Note the +: near the end of each line.
Is this legal Verilog? It looks illegal to me (and to Modelsim 5.5).
It looks
like an operator is missing. I don't believe Verilog allows this.
It also looks like the code couldn't possibly do the intended
initialization.
Has anyone else run into this?
Thanks for any help!
John Providenza
Article: 99292On 22 Mar 2006 08:44:13 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >Rather than relying on perfect alignment (and risking race conditions >if it is not met), I would deliberately offset the two clock domains. >Obviously, this lowers the max frequency of operation, but it really >makes things safe, if you have the timing margin. >Peter Alfke, Xilinx Applications I don't think this situation is any different than a regular 1x clock tree. One always has to check the clock arrival to both flops and the rest of the path etc. There is no need for perfect alignment. The source has its clock tree delay + clk->Q. If one sets the correct clock uncertainty in the timing constraints, this should be very easy to check for all pvt corners and fix by adding some small buffers if needed for clk1x to clk2x crossing flops.Article: 99293
This post is a bit of a flame, but seriously, JTAG has got to go. The
signals are weak. The various drivers and controllers for it are weak.
It causes nonstop headaches for hardware developers and FPGA developers
alike. It's slow, hardly customizable, hard to use, ultra extremely
fantastically flaky on every piece of FPGA hardware I've ever used
(which includes at least a dozen vendors), and ancient technology.
Here is what I want:
1. Support for a lot of chips, say 2048 of them. JTAG supposedly
supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
three or four. The 200KHz signal dies after eight or nine. This will
require some strong signals with error correction, but, heck, if a
basic ethernet layer can do it....
2. Endpoint enabling. The JTAG methods for specifying an endpoint are
both flaky and redundant. We need some nice protocols, maybe even
packets with headers, etc.
3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
And put some standard, accessible plugs on there while you're at it.
4. Standard driver interface. Need I say more? How many of you write
directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
you all enjoy it too. How about something like this:
mycard = code to locate the right driver and device and open it....
ioctl(mycard, HOW_MANY_DEVICES, &devices)
id_struct = new ID_STRUCT[devices]
ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
for each d in devices {
if( id_struct[d].devId == Virtex4Id ) {
targetlist = { d }
ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
command_struct.mode = programming
ioctl(mycard, SEND_COMMAND, &command_struct)
write(mycard, "c:\my programming file.bit")
ioctl(mycard, READ_STATUS, &status_struct)
if( status_struct.mode & programmed) break
else return failed
}
}
Then we go into a loop for reading and writing debug data, etc.
We could have drivers for a dozen different interfaces including
Firewire, parallel port (urrrg), serial port (double urrrg), etc.
Yo Xilinx, let's remove the great mystery from Impact. Let's open the
hat on the "platform" driver and make the thing useful for the parallel
port as well.
Maybe I'm taking this too far. I just want something that works
reliably and is not a pain in the ars to use programmatically. Is that
too much to ask?
Article: 99294Xilinx needs to go fsck itself.Article: 99295
While I agree with you that it is outdated and too slow,
I'd say some single chip USB 2.0 <-> much-faster-than-todays-JTAG
would be a practical enough solution. It will take care of the level
conversion and everything, and the speed will be as high as it
gets. Need more speed for too big a board, put several JTAG chains
on it, ready.
I do not understand what you mean by "the 5 MHz clock dies out after",
what's wrong with buffering it? But 5 MHz is too slow for todays big
chips anyway, so the point is valid nonetheless .
Now error correction, packet headers etc. sounds like
suggesting an entire tcp/ip for the backyard of something which
may not have as much in the front yard... that's a bit (way?) too far
for me.
We won't make a consumer interface out of JTAG, will we (I hope we
don't ... :-) .
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
Brannon wrote:
> This post is a bit of a flame, but seriously, JTAG has got to go. The
> signals are weak. The various drivers and controllers for it are weak.
> It causes nonstop headaches for hardware developers and FPGA developers
> alike. It's slow, hardly customizable, hard to use, ultra extremely
> fantastically flaky on every piece of FPGA hardware I've ever used
> (which includes at least a dozen vendors), and ancient technology.
>
> Here is what I want:
>
> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
> three or four. The 200KHz signal dies after eight or nine. This will
> require some strong signals with error correction, but, heck, if a
> basic ethernet layer can do it....
>
> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
> both flaky and redundant. We need some nice protocols, maybe even
> packets with headers, etc.
>
> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
> And put some standard, accessible plugs on there while you're at it.
>
> 4. Standard driver interface. Need I say more? How many of you write
> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
> you all enjoy it too. How about something like this:
>
> mycard = code to locate the right driver and device and open it....
> ioctl(mycard, HOW_MANY_DEVICES, &devices)
> id_struct = new ID_STRUCT[devices]
> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
> for each d in devices {
> if( id_struct[d].devId == Virtex4Id ) {
> targetlist = { d }
> ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
> command_struct.mode = programming
> ioctl(mycard, SEND_COMMAND, &command_struct)
> write(mycard, "c:\my programming file.bit")
> ioctl(mycard, READ_STATUS, &status_struct)
> if( status_struct.mode & programmed) break
> else return failed
> }
> }
> Then we go into a loop for reading and writing debug data, etc.
>
> We could have drivers for a dozen different interfaces including
> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
>
> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
> hat on the "platform" driver and make the thing useful for the parallel
> port as well.
>
> Maybe I'm taking this too far. I just want something that works
> reliably and is not a pain in the ars to use programmatically. Is that
> too much to ask?
Article: 99296Peter Alfke skrev: > Rather than relying on perfect alignment (and risking race conditions > if it is not met), I would deliberately offset the two clock domains. > Obviously, this lowers the max frequency of operation, but it really > makes things safe, if you have the timing margin. > Peter Alfke, Xilinx Applications I think I remember Ray saying perfect alignment could not be relied upon especially if the load on the two net were very different -LasseArticle: 99297
> And what's the difference with integer and reg signed [31:0](2's > complement) ? 1) You need [at least partial] 2001 support to use "reg signed". It isn't in the 1995 standard. 2) A variable declared integer is not necessarily exactly 32 bits wide. If I recall correctly, it must be at least 32 bits wide, but it could be 64 bits wide if that were more convenient to the implementation. 3) In some implementations, I have found wierd artifacts occur when using integers in calculations that were longer that 32 bits wide, they didn't necessarily sign extend in consistent ways past the 32 bit length, sometimes they would sign extend and other times that would 0 pad. 4) You can't do bit-selects or part-selects on integers, just on regs (and wires, et al). 5) You shouldn't use "integer" declarations for things like flops or signals that will exist as actual circuitry (partially because of 2 through 4). You should use integer declarations only for for look indexes and similar items that "go away" as the design is turned into silicon. You can use integers in non-synthesizable code, e.g. testbench parts. Thus, if your tools are modern and support the current standard, you should use "reg signed" when you want a synthesizable part that works in a signed way. If you don't have modern tools, life is more difficult.Article: 99298
I incorrectly said: > through 4). You should use integer declarations only for for look I meant: > through 4). You should use integer declarations only for for loop > indexes and similar items that "go away" as the design is turned -ChrisArticle: 99299
Davy wrote: > I heard that Verilog has integer type. > Someone said integer can be signed or unsigned. > How to declear signed integer? Integers are always signed, and (usually, see Chris Clark's comment) 32 bits wide. > And what's the difference with integer and reg signed [31:0](2's > complement) ? Nothing, but it's often a convenience to have a signed value that is not 32 bits wide. -a
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