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
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3B86F821.87AD4921@xilinx.com...
<big snip>
> > >> 7) How about guaranteed best case timings as well ?
> > >> ( specifically for BRAM access)
> > >
> > >some day
> > >
> > Sorry It's just that I could have sworn that Xilinx indicated the
availability
> > of this data several months ago.The indication was in tabular form.
>
> Maybe for Virtex, Virtex E, but I doubt it for Spartan II. I'll ask.
Isn't 'best case' timing only valuable in the sense of
"path X will never be faster than path Y"
so that we can avoid races. Otherwise, use worst case.
(I guess tricky clock-doublers are the exception)
Article: 34476Mark, Austin > > >(snip) > So is there zero skew on the Data out lines ? > Or is the skew the difference between Tbcko max & min (1.25ns approx) ? > Or do we use a margin such as 10% of Tbcko max (0.33ns) ? Assume no skew. Let the tools do their job. The min and max is for overall timing. Of course there is some skew, but it is so small as to be difficult to measure, let alone characterzie. That is why we depend on the tools to yield a place and route with sufficient margin.Article: 34477
Simulation works because the sensitivity list in your combinatorial blocks (always@(sysclk)) only gets executed when sysclk changes. Synthesis won't provide you with the same kinds of results - you have to either think in terms of registers (for a synchronous shift register) or produce some kind of master/slave equivalent to get a true asynch system going. Asynch is almost never the right way to design. The combinatorial logic produced should end up with the led_1, led_0 assignments being made continuously while ~sysclk&&~last_ser_clk&& ser_clk not just when sys_clk changes. This should be visible in the synthesized results but should not simulate as the shift register you expect. I'd think you'd see a warning message in your synthesizer talking about an "incomplete sensitivity list." The incomplete lists can do nice things for simulation but not for synthesis. Fred wrote: > Hello, > > Just to get familiar with the basics of verilog and all that I tried to make > a 16 bit shift register, and show the contents on a led display. > > In simulation it does all it's supposed to do. I do my simulations with > Icarus Verilog 0.5 (g++-3.0). Now when I compile it to the target hardware, > still everything is tip-top. As hardware I'm using a Post-It board, which > has an Altera EPM3128ATC100-7 on it. [http://www.cmosexod.com/board.htm] > For synthesis I use Max+plusII version 10.0 9/14/2000 (2000.09) from Altera. > It even programs OK. So what's the problem I hear you say? > > As inputs I have async_ser_clk and async_ser_clk, which change out of sync > with the system clock of the CPLD. So on the posedge of the system clock I > latch those to two registers to synchronize them. For debugging purposes I > also latch them into two of the four led displays. On the negedge of the > system clock I then check if the synchronized ser_clock has gone from low to > high, and if so, shift the register. > > Now the problem is this: > It does seem to synchronize the ser_clock, and does _something_ on the low to > high transition. Only that something should be shift the register, like this: > (See also the appended source-code) > led_1[7] <= led_1[6]; > led_1[6] <= led_1[5]; > ... > led_0[1] <= led_0[0]; > led_0[0] <= ser_dat; > > What it seems to do instead is: > led_1[7] <= ser_dat; > led_1[6] <= ser_dat; > ... > led_0[1] <= ser_dat; > led_0[0] <= ser_dat; > > It doesn't shift, it changes _ALL_ 16 bits of the 'shift'-register to either > 1 or 0, the value of ser_dat. Oh, and before I forget, I don't think it's a > timing problem, since for debugging I use a system clock of 200 Hz, and > change the async_ser_clk and async_ser_dat on the touch of a button (== as > slow as I want). So did I make a stoopid mistake somewhere, and should it > compile to this, or is something else going on? > > any help appreciated, > Fred <snip> > always @(sys_clk) begin > if (sys_clk) begin > // @(posedge sys_clk) --> synchronize ser_clk and ser_dat > last_ser_clk <= ser_clk; > ser_clk <= async_ser_clk; > ser_dat <= async_ser_dat; > end else begin > // @(negedge sys_clk) --> use synchronized ser_clk and ser_dat > led_3[7] <= ser_clk; > led_3[6] <= ser_clk; > led_3[5] <= ser_clk; > led_3[4] <= ser_clk; > led_3[3] <= ser_clk; > led_3[2] <= ser_clk; > led_3[1] <= ser_clk; > led_3[0] <= ser_clk; > > led_2[7] <= ser_dat; > led_2[6] <= ser_dat; > led_2[5] <= ser_dat; > led_2[4] <= ser_dat; > led_2[3] <= ser_dat; > led_2[2] <= ser_dat; > led_2[1] <= ser_dat; > led_2[0] <= ser_dat; > > if ((~last_ser_clk) && (ser_clk)) begin > // @(posedge synchronized ser_clk) > // shift ser_dat through > // led_1 <-- led_0 <-- ser_dat > led_1[7] <= led_1[6]; > led_1[6] <= led_1[5]; > led_1[5] <= led_1[4]; > led_1[4] <= led_1[3]; > led_1[3] <= led_1[2]; > led_1[2] <= led_1[1]; > led_1[1] <= led_1[0]; > led_1[0] <= led_0[7]; > > led_0[7] <= led_0[6]; > led_0[6] <= led_0[5]; > led_0[5] <= led_0[4]; > led_0[4] <= led_0[3]; > led_0[3] <= led_0[2]; > led_0[2] <= led_0[1]; > led_0[1] <= led_0[0]; > led_0[0] <= ser_dat; > end // @(posedge synchronized ser_clk) > end > end // always @ (sys_clk) > endmodule // shift_leds <snip>Article: 34478
Consider trying not to add extra clocks just because it's easy to add one element (a counter) that works simply with an individual clock. Often other factors are complicated because the element is asynchronous with other parts of your design. If you're reading the counter with another system clock, what happens when you read the value during an increment? If your read is synchronous you'll either have the previous or next value, no in-between. My suggestion is to look for the rising edge and generate a single registered signal for one system clock period. When that one register is valid, enable your count. Everything falls into place. Someone could provide a quick code snippet if you let us know your language - verilog? vhdl? ahdl? Schematics are tough to do in the newsgroup. Jan Pech wrote: > Hi all, > I have some problem with my design in Xilinx WebPACK. I need to count events > on an I/O pin. When I specify the pin number for counter clock signal in UCF > file, the map process generates error 93 .......IPAD-IBUFG should only be > LOCed to GCLKIOB site. > I tried to instantiate BUFGP and BUFGDLL primitives between the I/O pin and > internal clock signal but they may be used with GCLK pins only. > Is there any way to drive clock signal for counter by an general I/O pin? > > Thanks for your help! > > Regards, > Jan > > ___________________________ > j.pech@sh.cvut.cz > +420 (723) 760802 > ICQ: 56431283Article: 34479
Greetings everyone, Does any there know of a DUART core (compatible with 16C550) that is free, and that can be synthesized for a Xilinx FPGA (Spartan II). Even if it isn't ready for synthesis, but that the source code in VHDL or Verilog is available would be of great help. Thank you in advance. Marco.Article: 34480
"H.L" <alphaboran@yahoo.com> wrote in message news:9mcvnp$1r11$1@ulysses.noc.ntua.gr... > Hello all, > I am going to program a Xilinx FPGA for the first time. I wanna setup the > synthesis tools on a pc, what must be the system's requirements for proper > (and relatively fast) function? > Thanks > > It obviously depends on the size and complexity of your design. I find a 1 GHz Athlon with 512 Mbytes of RAM works quite well with the Xilinx and Altera tools. Leon -- Leon Heller, G1HSM leon_heller@hotmail.con http://www.geocities.com/leon_heller Low-cost Altera Flex design kit: http://www.leonheller.comArticle: 34481
Speedy Zero Two wrote: > > Hi Rick, > > I already have control of the dram so know the refresh is ok but will > probably modify the code for future design checking. > What I found in the verilog code confirmed what I thought, I am already > using the burst mode but for a single "word". > Now all I have to do is change the mode register to give the required burst > length (which is all I really need). Part of your logic should be setting that mode register at initialization time... -aArticle: 34482
I did not expect to participate in this pointless argument, but enough is enough... Austin Franklin wrote: >> but so does "proper >> use of schematics", correct? > > Er, no it doesn't. Same schematic, same results. Errr... If I do schematic entry, I expect from a good tool chain, that it performs at least the following optimizations: - logic minimization - redundancy elimination - retiming - logic replication for speed-up - technology mapping There are many algorithms for these optimizations and even if there wasn't the results would depend on the order the circuit is processed in. Also, there are area, speed, power and testability trade-offs in these steps and relative weights may differ from version to version. Of course you can draw schematics that are completly based on technology dependant elements so there is no technology mapping. Probably your tool is one of the many that does not implement retiming. One point for predictability but minus ten for performance. You probably turned off logic replication for your tool because you believe that you can handle that manually. You don't. Not for large designs. Especially not if retiming is involved. And of course your schematics are allready minimal and do not contain any redundancies... The only way to be really sure what comes out of the tools is to do it manually. (The assembler equivalent) You can do that in JBits, FPGA Editor, low level schematic entry and structural VHDL using library primitives.. But time to market wise state machine diagrams, high level schematic abstraction or higher level hdl are going to beat you by huge factors. And also performance wise: Especially simultaneous retiming and placement is somthing that you can hardly do manually and it can get you a huge performance boost... Kolja SulimmaArticle: 34483
- Grayscale (8 bit) video input - Compression only, baseline lossy JPEG (ISP/IEC 10918-1) only required - VHDL or Verilog - Planning on targetting an FPGA Thanks in advanceArticle: 34484
In article <3b86ed56.46990212@news.compuserve.com>, 101551.3434@compuserve.com (Mark Taylor) wrote: >On Fri, 24 Aug 2001 00:19:48 GMT, arast@inficom.com (Alex Rast) wrote: > >>This is one I think I've done before, so I probably just need my memory >>jogged. I'm sure it's something that happens, and that you need, all the time. >> >>I've defined a hard macro, call it custommacro.nmc. .... Now, at least one of the nets connects to an >>external pin and an internal route. One common example, for instance, is CLK. >>You want the signal to be common to the internal CLB's of the macro and to >>connect to external routes (in the case of CLK, to the global clock net). >> > >As far as I know, nets could never be included in hard macros. >(despite documentation suggesting otherwise, right back to before EPIC) No, I have no problem including a net in a macro. What I have difficulty doing is routing an external net *to* the macro's internal net. >Just use the hard macro to configure slices/CLBs or whatever, >then embed the macro within a soft macro > (ie a schematic macro with RLOCS). >The soft macro can contain all the routing. I don't think this would work, for 2 reasons. First, I *have* to have a specific routing within the hard macro (indeed, the routing itself is a key part of the design), so I can't afford to let the software take care of any routing at the hardware level. Second, a lot of the things we're doing are functions you simply can't enter properly in Schematic Editor, not because you can't implement them on-chip, but because the programmers didn't anticipate you'd be doing these kinds of functions. Just for giggles, I decided to input the closest approximation to our macro you could do in Schematic Editor. The resultant imlementation, in addition to being close but not exactly the same in functionality, occupied 6 times as many CLB's! This is kind of the result I was expecting, because it's clear the program doesn't think of or implement resource reuse, i.e. using the same logic elements to implement multiple functions, nor will it use multiple data paths within the same CLB, i.e. using different data outputs to generate different function outputs. It thinks of a CLB slice implementing one function. Are you thinking along some other line? If so, can you clarify what your approach would be? Alex Rast arast@inficom.com arast@qwest.netArticle: 34485
Hi all, at the moment I'm thinking of using an FPGA from brand X to implement a USB interface. What I heard from brand X is that I should translate USB with 'You shouldn't bother' but that's not an answer I really want. So I'm wondering if anyone out there has successfully implemented a USB-interface in a Xilinx-FPGA or is this really something I should do in another way? Help would be very much appriciated. MoadlArticle: 34486
You might check out the following from OpenCores.org http://www.opencores.org/cores/uart16550/ mcastellon@csi-wireless.com (Marco Castellon) wrote in message news:<852c162d.0108270851.215952d1@posting.google.com>... > Greetings everyone, > > Does any there know of a DUART core (compatible with 16C550) that is free, > and that can be synthesized for a Xilinx FPGA (Spartan II). > > Even if it isn't ready for synthesis, but that the source code in VHDL or > Verilog is available would be of great help. > > Thank you in advance. > Marco.Article: 34487
One of my customers would like an FPGA converted to a pin for pin compatible ASIC, in order to try to prevent counterfeit versions of their product being manufactured. I have used ASIC Technical Solutions (ATS) for this successfully in the past, but they seem to have disappeared. I am looking at AMIS and Flextronics. Does anyone know of any other companies, or have any other suggestions? Many Thanks, Ken Morrow, Morrow Electronics Limited, UK.Article: 34488
kenm@morro.co.uk (Ken Morrow) wrote: >One of my customers would like an FPGA converted to a pin for pin compatible >ASIC, in order to try to prevent counterfeit versions of their product being >manufactured. > >I have used ASIC Technical Solutions (ATS) for this successfully in the past, >but they seem to have disappeared. > >I am looking at AMIS and Flextronics. > >Does anyone know of any other companies, or have any other suggestions? > >Many Thanks, > >Ken Morrow, >Morrow Electronics Limited, UK. Check out http://www.simtek.com/Logic/logic-overview.htm. A client of mine is currently using them to convert an Altera 10K design. MuzafferArticle: 34489
Try asking in comp.dspArticle: 34491
Depending on the volume might it not be cheaper to go with an anti-fuse part for this? ASICs are actually __easier__ to counterfeit than anti-fuse parts. Eric "Ken Morrow" <kenm@morro.co.uk> wrote in message news:20f8de50.0108271332.3378e62e@posting.google.com... > One of my customers would like an FPGA converted to a pin for pin compatible > ASIC, in order to try to prevent counterfeit versions of their product being > manufactured. > > I have used ASIC Technical Solutions (ATS) for this successfully in the past, > but they seem to have disappeared. > > I am looking at AMIS and Flextronics. > > Does anyone know of any other companies, or have any other suggestions? > > Many Thanks, > > Ken Morrow, > Morrow Electronics Limited, UK.Article: 34492
I think you can use the new Virtex II bitstream encryption in this case. If the customer ships the board, I think they can program encryption keys into the VirtexII in the factory. Then they encrypt their bitstream with the same key. Then the board can't be reverse engineered. A reverse engineer could intercept the bitstream as it programs the Virtex, but if he tries to program another Virtex with the same bitstream, it won't work because he first has to program the Virtex encryption key, which can't be read from the original part. -Kevin "Ken Morrow" <kenm@morro.co.uk> wrote in message news:20f8de50.0108271332.3378e62e@posting.google.com... > One of my customers would like an FPGA converted to a pin for pin compatible > ASIC, in order to try to prevent counterfeit versions of their product being > manufactured. > > I have used ASIC Technical Solutions (ATS) for this successfully in the past, > but they seem to have disappeared. > > I am looking at AMIS and Flextronics. > > Does anyone know of any other companies, or have any other suggestions? > > Many Thanks, > > Ken Morrow, > Morrow Electronics Limited, UK. >Article: 34493
Austin Franklin wrote: > > > > > > Yet the majority of designs are done in HDL for > > > > > > good reasons: less effort, better results. > > > > > > > > > > You have no proof of this. > > > > > > > > That's correct, for I don't think such things can be proven. Do you? > > > > > > Then why did you make a claim that you know isn't true? > > > > As Godel showed, propositions can be both true and unprovable. > > Well, then I clam that schematics are less effort and give better results. I agree with you, for designs that are both large and are not complex, or for which large amounts of effort can be expended for marginal improvements. > > > I've done a number of designs in both, and schematics win hands down to > > > finished product every time, except for the simplest/slowest designs. > > > > Back when synthesis got started, designers were drawing transistors on > > schematics and wanted a faster way to an acceptable answer. Sure, by > > calculations and experience the human designer can produce a nearly > > optimal design for a bit of logic (say for the carry bit of an ALU, > > perhaps some 20 or 30 transistors, using many hours of human designer > > time: but a simple synthesis tool can do nearly as well in seconds. By > > freeing the designer from the tiny details of transistors and gates, > > much more complex designs could be completed. > > I don't get your point. There is no need to draw gates with schematics, any > more so that you do with HDLs. I'd bet that the schematics for "our beloved FPGAs" have gate sizes on them. I might be wrong, I've been out of the semiconductor world for a long time. > > > There can be way too much fussing with timing and tools etc. with > > > synthesis. When synthesis works, it works, and that's nice...but > > > there is no guarantee that it will, and if it doesn't, the amount > > > of time it takes to get it to work can be exponential, or even > > > complete failure. > > > > When I write code I know fairly closely what the synthesis tool is going > > to produce, > > Do you look at the gates that the synthesis tool generates? Often. Usually on critical paths, or on close to critical paths where the synthesis tool didn't build good logic or where MAP and/or PAR needed some hints and one of these issues caused the design to fail timing on these paths. And yes, the shame of it, the viewer is a schematic viewer (Synplicity's "technology view"). And yes, the solution is often "schematic VHDL", i.e. instantiate LUTs. In designs I've done the amount of LUTs that needs this sort of treatment has averaged less than a few percent of the total. > > and how fast it will run. This takes experience, > > More than experience. It takes only using one revision of one tool! The > synthesized code will give different results based on a LOT of variables, > even point revisions of the tools. You can't guarantee that. If you want the best guaranteed results, specify gate sizes and do the layout yourself, and don't expect to do many complex designs in your lifetime. The best is the worst enemy of the good. > Unless there > is a document that synthesis tool vendors provide that shows EXACTLY what > code is generated for each construct, what you suggest just isn't going to > work. This can be done, if required. Not for "each construct", but you can build an EXACT design by mapping primitive elements. Yet why bother, for complex designs, except for the critical paths? Let the tool handle all but the critical stuff. -- Phil HaysArticle: 34495
Hi. I need the IEEE 1149.1-1990 standard, I am not interrested in paying IEEE for the book, so .pdf is preferred / Daniel NilssonArticle: 34496
I want to ask a question about the synthesis and simulation. After synthesis with the syplify, how can i do a post-simulation. And what must be noted in the process of synthesis and simulation(detailed ). Thank you .Waiting for your reply.Article: 34497
On Mon, 27 Aug 2001 20:07:04 +0200, Kolja Sulimma <kolja@sulimma.de> wrote: >I did not expect to participate in this pointless argument, but enough is >enough... And I didn't think I would ever defend Austin Franklin (he does well enough on his own), but this is outrageous. But just so you have me pegged correctly for this flame fest, note that I am an active user of Verilog and Schematic, and have done more than enough VHDL too. I actively use Verilog in my day to day consulting, by choice. >Austin Franklin wrote: > >>> but so does "proper >>> use of schematics", correct? >> >> Er, no it doesn't. Same schematic, same results. > >Errr... >If I do schematic entry, I expect from a good tool chain, that it >performs at least the following optimizations: > >- logic minimization >- redundancy elimination >- retiming >- logic replication for speed-up >- technology mapping So are we talking about the schematic flow upto the point where the netlist enters something like the Xilinx place and route tools, or are we talking about including that too? The 5 items you list are all performed by sythesis before the netlist is passed to the P&R tools. None of the 5 things you list should be done in a schematic flow before the netlist is passed to the P&R tools. Once the P&R tools get the netlist, both flows look the same. In Xilinx's case, the current tools perform items 1, 2, 4, and 5 . Item 3 does not occur in the Xilinx P&R tools currently. For each of the optimizations that the P&R tools perform, there are cases where the result is disastrous. One of the still most compelling reasons to still use schematics, is that there are reasonably easy ways to inhibit this behaviour. I would be outraged if a schematic base tool chain did ANY of these things to the netlist before passing it on to the P&R tools, the way synthesis does. One of the most compelling reasons for using schematics is that you get EXACTLY what you ask for. Certainly for expert users of FPGAs, the skills and understanding of the target architecture allow for designs that extract the very most out of what the chip can achieve. This often far outperforms what synthesis tools create, because synthesis tools can't see the big picture, and it makes pessimizations. (And if you didn't think "pessimizations" is a word, try this: http://www.google.com/search?q=pessimizations&btnG=Google+Search ) Of the 5 example design permutations you list (what you call optimizations) here is the score for the following schematic systems, upto the point where the netlist is passed to the P&R tools. ViewDraw: NONE Orcad: NONE Aldec: NONE Cadence: NONE ECS: NONE FutureNet: NONE Schema: NONE Protel: NONE I wonder if there is a theme here. It seems none of the schematic systems I have listed do any of the "optimizations" you said are expected from a schematic flow. Here's your quote again: >If I do schematic entry, I expect from a good tool chain, that it >performs at least the following optimizations: But maybe you meant the whole tool chain, including P&R. But then, as I have pointed out, these optimizations have nothing to do with the pros/cons of using schematics. Now, if you didn't care about getting the most out of the FPGA, or cared far more about design time, you can skip the rest of what I have to say. >There are many algorithms for these optimizations and even if there >wasn't the results would depend on the order the circuit is processed in. >Also, there are area, speed, power and testability trade-offs in these >steps and relative weights may differ from version to version. None of which has anything to do with the schematic part of the flow. >Of course you can draw schematics that are completly based on technology >dependant elements so there is no technology mapping. Or you can use technology independent libraries, like the current Xilinx Unilib libraries, where the technology dependence is hidden in the schematic library, and the top level symbols that you use are technology independent. Unlike synthesis, where I have to push a design through the tools before I have a hope at finding out how something will be mapped, with the technology independent schematic library, I just push into the sub page of the symbol, and I see the technology dependent implementation. For example, the Xilinx Unilib library has a 16 bit counter called CC16RE, and the symbol is identical, regardless of the target FPGA technology. A schematic that uses it will work regardless whether the target is any of the following: XC4000 / XC4000E / SPARTAN / XC4000EX / XC4000XL XC5200 VIRTEX / SPARTAN-II VIRTEX-II The implementation is different for each of these, yet you can do technology independent designs, with design reuse, just fine. >Probably your tool is one of the many that does not implement retiming. >One point for predictability but minus ten for performance. Boy would I be pissed if the Schematic part of the flow thought it could do pipelined design better than me. >You probably turned off logic replication for your tool because you >believe that you can handle that manually. >You don't. Not for large designs. Especially not if retiming is involved. That may be your problem, but I know Austin well enough, that if he decided that he could do logic replication or pipeline partitioning better than the tool flow, it would be because he could. And it would probably be because he had already seen the tools make a complete mess of it. I've certainly seen the tools take a perfectly reasonable design that could meet the design goals, and turn it into mush. >And of course your schematics are allready minimal and do not contain >any redundancies... Right. >The only way to be really sure what comes out of the tools is to do it manually. >(The assembler equivalent) Wrong. >You can do that in JBits, FPGA Editor, low level schematic entry and structural >VHDL using library primitives.. And with high level schematics too. I.E. with complex macros, and sophisticated libraries, and design re-use, and generated IP, and purchased cores. >But time to market wise state machine diagrams, high level schematic abstraction >or higher level hdl are going to beat you by huge factors. Well, Austin and I disagree. >And also performance wise: Especially simultaneous retiming and placement is >somthing that you can hardly do manually and it can get you a huge performance >boost... Totally disagree. Just because (you?) can hardly do it does not mean others can't . >Kolja Sulimma Looking for a flame proof vest ..... Philip Freidin Verilog and Schematic user. .... count to ten .... hit send :-) Philip Freidin FliptronicsArticle: 34499
Hi, I want to download a bitstream (*.bit file) to a Xilinx FPGA (e.g. xcv600) through a DB9 serial cable (model: DLC4). Must I use the tools provided by Xilinx? Is there any possibility I can write a segment of codes to do this in my application? Thanks in advnce! ---- Brittle
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