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
I believe that you need to give XST hints to infer logic that maps onto
the architecture. I was at a Xilinx presentation where they used the
RSE letters to denote the order of priority that operations need to
be entered in order to map onto the flip-flop efficietnly:
always @(posedge clk)
if (Reset)
// reset stuff 1st
else if (Set)
// set stuff second
else if (Enable)
// enabled logic last
This is because of the priority of the Reset/Set/Enable functions built
into
the flip-flops.
It could be that the original code fragment confuses the code
generator.
John P
Article: 93401See the things in you design which are always @ (posedge xyzzy) begin foo <= bar, the xyzzy is a clock, even if you don't call it clock. The foo <= bar is an "edge clocked" flip-flop/register. Things happen on the posedge of the xyzzy clock. If the clock is "periodic" hooked up to some kind of oscillator, then it is obvious that it is a clock. However, even if the clock is not periodic, it is still a clock and it tells "when" something happens. Hope this helps, -Chris ***************************************************************************** Chris Clark Internet : compres@world.std.com Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours) ------------------------------------------------------------------------------Article: 93402
Hi, Xilinx have filed for 22 patents to implement 8B/10B algorithm. IBM filed the 8B/10B original patent in 1981. Now 8B/10B algorithms are so popular that all SERDES specifications use the 8B/10B like what ASCII is to computer industry. Most of 22 Xilinx 8B/10B patents are pending. You may print out what have been approved as a patent. Their experiences will certainly help you do understand how to design a 8B/10B circuit. Sorry, all those circuits are still pending. One that is approved is a software flow map. WengArticle: 93403
Reza Naima wrote: > Santosh - > > I'm not sure if I understand your question, or what an RTL stands for. > Based on the feedback, I rewrote the module so it looks like this (and > is much simpler looking) : > > module counterLatch32(counter_increment, in, reset, enable, out); > input in; > input counter_increment; > input reset; > input enable; > output [31:0] out; > > reg [4:0] index; > reg [31:0] out; > > always @(posedge counter_increment or posedge reset) begin > if (!reset) > index <= index + 1; > else > index <= 5'b00000; > end > > always @(posedge enable) > out[index] <= in; > > endmodule > > I still don't see a need for a clock - can someone shed some light into > a case where a clock would be helpful? I'm still getting errors. Just > this one so far.... THINK HARDWARE. What sort of logic will this code create? Answer: some flip-flops. And flip-flops require a clock to change state. In the example you give above, the signal counter_increment is used as the flops' clock input. (You might want to read the synthesis tool manual to learn why.) The other gotcha that you probably don't realize is that the signal enable will ALSO be used as a clock for the flips in the signal out. On every rising edge of enable, the value of in will be clocked into out. Again, a simple perusal of the synthesis tool manual will explain why. > ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test > condition for <index> is incompatible with the event declaration in the > sensitivity list. That's because your code doesn't follow the templates for synthesizable flip-flops. Specifically, you can't do anything "more complex" than assigning constants (the reset values) to the flops in the if (reset ...) clause. The other reason for the error is that the asynchronous reset has priority over the synchronous update. You've coded it such that the synchronous update has the higher priority. -aArticle: 93404
Reza Naima wrote: > I think John answered the question by stating that the clock is useful > for syncronization and debugging, but ultimatly it seems as if I am > correct in my assertion that a clock is not explicitly required. Not knowing the details of your design makes it a bit difficult to tell whether a global clock is necessary, but the reason for synchronous design (the entire design clocked by a global clock) is that is simplifes timing analysis and helps to ensure that the design will actually work. > Digital electronics design seems a bit vague - can you be a bit more > specific? There are verilog-specific courses offered in my program > (I'm in graduate school) - but I think it's an overkill for my needs. I'm actually talking about Digital Electronics Design 101 -- back to basics. > Alas, the current project I'm working can't wait for me to take more > classes. Either this is implemented in a CPLD or else I'll have to use > discrete components. I'm going to follow some of Art's suggestions and > see how far I can get. Can the project wait for you to develop the skills to ensure that it is successful? > With regards to a wait(), I figured the compiler/synthesizer would > generate some sort of clock/counter with some sort of comparator to > trigger the event. I was hoping that the synthesizers were a bit > smarter than they seem to be. The synthesizers _are_ very smart, but you don't want them to be too smart. The tools are capable of generating logic that may be functionally correct, but may be too large to fit in a chip, or may not run at the required speed, or both. Writing concise descriptions allows the tools to produce a more optimal result. -aArticle: 93405
bjzhangwn wrote: > I am interest in the embeded system in the fpga,but I have no money to > buy the board from xilinx or altera,Anyone who have it can share your > schematic and the docs?thanks! You can download the schematics and example code for various development boards from Xilinx and Altera's web sites. If you don't have the money to buy the board, it's not likely you'll have the money to fabricate your own. -aArticle: 93406
Below is the code I use to mux 8 asynchronous clocks on a Spartan3. I guess this method is safer than using LUT muxes as long as SEL is static in all clock domains. Now, what would be the best way to cut all timing analysis from the input clocks to the output clock? Of course I also want to specify a new period on the output clock (preferably without routing it outside the chip and back). --- entity clkmux8 is Port ( CLK0 : in std_logic:='0'; CLK1 : in std_logic:='0'; CLK2 : in std_logic:='0'; CLK3 : in std_logic:='0'; CLK4 : in std_logic:='0'; CLK5 : in std_logic:='0'; CLK6 : in std_logic:='0'; CLK7 : in std_logic:='0'; SEL : in std_logic_vector(2 downto 0); CLKOUT : out std_logic ); end clkmux8; [...blabla...] mux10:MUXCY port map (S=>SEL(0),O=>tclk10,CI=>CLK1,DI=>CLK0); mux11:MUXCY port map (S=>SEL(0),O=>tclk11,CI=>CLK3,DI=>CLK2); mux12:MUXCY port map (S=>SEL(0),O=>tclk12,CI=>CLK5,DI=>CLK4); mux13:MUXCY port map (S=>SEL(0),O=>tclk13,CI=>CLK7,DI=>CLK6); mux20:MUXCY port map (S=>SEL(1),O=>tclk20,CI=>tclk11,DI=>tclk10); mux21:MUXCY port map (S=>SEL(1),O=>tclk21,CI=>tclk13,DI=>tclk12); mux30:MUXCY port map (S=>SEL(2),O=>CLKOUT,CI=>tclk21,DI=>tclk20);Article: 93407
Thank you very much for the information Kolja. I greatly appreciate the information that you included in your reply. Best Regards, Marco.Article: 93408
I am working on a project that is taking a clock and inerfacing it with a PLL to get a set of variable clock divisions. I am using the digilent s3 board as a devolopment tool, and have been getting caught up on how to use the expansion ports as generic I/O pins to output the clk signals to test. I assign output and input ports to the FPGA pins that match up to the expansion port pins through the ucf. But the waveform I keep getting out of the pins are all the same. Even the VCC and ground pins output this bizzare waveform. Am I missing an enable pin somehwere on the board or do I need to power up the ports? Or is there another way to output test clk signals somewhere on the board? Any help would be much appreciated.Article: 93409
Hello, everyone!
I am trying to adapt Spartan 3 Starter Kit board as a standalone board
for one of my projects.
To download configuration to FPGA I want to use 6 pin serial JTAG.
My question is: are there any strict specifications for the line
driver that drives TDO line back to the PC? Any links addressing this
issue would be very welcome!
TMS, TCK, TDI lines are driven by drivers inside the Xilinx parallel
cable (which take the power from PC parallel port). They are Schmitt
trigger type and quite fast: NL37WZ17
I was wondering if the TDO line buffer/driver needs to adhere to
similar specifications?
The board is to operate @ 3V.
Thank you!
Article: 93410Hello Everyone iam new this grp sole reason to join this group is that i am finding myself unable to find a suitable algorithm for the mouse . I have P89LPC922 microcontroller i am contantly searching net for an algorithm to solve maze but it only gives me a hint towards Bellmans algorithm. We have sat on paper but not getting a foolproof algorithm. Can anyone help me Anshat Singhal MNIT Jaipur IndiaArticle: 93411
"Renniks" <jks2999@rit.edu> schrieb im Newsbeitrag news:r7SdnXIbMPRQDjTenZ2dnUVZ_vmdnZ2d@giganews.com... >I am working on a project that is taking a clock and inerfacing it with a > PLL to get a set of variable clock divisions. I am using the digilent s3 > board as a devolopment tool, and have been getting caught up on how to use > the expansion ports as generic I/O pins to output the clk signals to test. > I assign output and input ports to the FPGA pins that match up to the > expansion port pins through the ucf. But the waveform I keep getting out > of the pins are all the same. Even the VCC and ground pins output this > bizzare waveform. Am I missing an enable pin somehwere on the board or do > I need to power up the ports? Or is there another way to output test clk > signals somewhere on the board? Any help would be much appreciated. > > you can probably measure the same waveform on your finger too? try connecting ground to your measuring equipment, then there should not be any more large noise on the ground pin. the ports need to be configured as outputs and VCC IO in those banks need to be present, that all what is needed to output an signal AnttiArticle: 93412
>> I still don't see a need for a clock - can someone shed some light into >> a case where a clock would be helpful? I'm still getting errors. Just >> this one so far.... >> >> ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test >> condition for <index> is incompatible with the event declaration in the >> sensitivity list. >> >> >> reza >> Asynchronous logic does not belong in FPGAs. They are not designed for it and the tools don't support it (especially static timing analysis). Wires in FPGAs have delays associated with them that are on the same order of magnitude as the delays through the logic primitives. While your ripple count structure is a viable clock structure, it does have some things you need to watch out for: 1), the outputs do not update all at once, rather the lsb changes, then the next bit and so on, hence the name ripple count. As the counter gets wider, the maximum count speed at which you can extract a usable count diminishes (but note that if you don't need the lower order bits, this can be faster than a synchronous counter). 2) The input is sensitive to glitches on the input signal. Mechanical switches will 'bounce', so you'll need to include logic to filter out the multiple switch closures that happen every time you actuate the switch. Timing analysis (studying the time delays in your circuit to make sure that it will run as fast as you need it to and that it won't break because of signals getting somewhere either too fast or too late) is much easier in a synchronous design (one where a common clock is distributed to all the flip-flops in the design) because each timing path is punctuated by the flip-flops...you only need to evaluate the propagation delay time from flip-flop to flip-flop. In an async system, you need to take into account the propagation delays on all paths from the input to the output to make sure you don't have race conditions that would upset the proper operation of your circuit. Also, synchronous design eliminates the dynamic hazards you need to deal with in an async design. Even asynchronous resets are bad for FPGA design. First, the tools don't trace the delay paths for the asynchronous reset through the flip-flop, so you could wind up with timing hazards and not be aware of it. Second, there are start up hazards which have been discussed ad nauseum here in the past. If you really need an async behavior, for whatever reason, just connect the external async reset to the PROGRAM pin on the FPGA.Article: 93413
I stand corrected. My response was directed at the suggestion: "I can come up with a better P&R implementation for Xilinx or Altera chips". As Kolja also might agree, an industrial-strength complete solution involves massive efforts that only the major companies can afford. But a novel algorithm, a completely different way of attacking the problem, can more easily come from a few individuals who are not burdened with maintaining legacy designs, or with the expectation of completing their project to industrial strength. Without such burdens, they can explore more freely, and such exploration has been fruitful in the past, and might well be in the future. I stand corrected. Peter AlfkeArticle: 93414
I don't have the Starter Kit schematic to hand so this is a general statement. If the Spartan-3 is the last device in the chain then you should have sharpish edges on TDO as Spartan-3 has an active totem-pole o/p for TDO. This is not always the case as some Xilinx devices have an open drain drive and rely on a pullup for the high level. In the later edges can be slowish so schmitt is possibly better. That said Parallel Cable III uses 74xx125 drivers which are not schmitt. John Adair Enterpoint Ltd. - Home of Raggedstone1. The $90 Spartan-3 Development Board. http://www.enterpoint.co.uk "Telenochek" <interpasha@hotmail.com> wrote in message news:1135187684.760646.76040@o13g2000cwo.googlegroups.com... > Hello, everyone! > I am trying to adapt Spartan 3 Starter Kit board as a standalone board > for one of my projects. > To download configuration to FPGA I want to use 6 pin serial JTAG. > My question is: are there any strict specifications for the line > driver that drives TDO line back to the PC? Any links addressing this > issue would be very welcome! > > TMS, TCK, TDI lines are driven by drivers inside the Xilinx parallel > cable (which take the power from PC parallel port). They are Schmitt > trigger type and quite fast: NL37WZ17 > I was wondering if the TDO line buffer/driver needs to adhere to > similar specifications? > The board is to operate @ 3V. > > Thank you! >Article: 93415
Peter Alfke schrieb: > As Kolja also > might agree, an industrial-strength complete solution involves massive > efforts that only the major companies can afford. Full ACK. For my contributions to that area it usually is required to check the benchmarks beforehand for special cases the tools can not handle. E.g. it is just not worthwile for research to handle wires that go directly from inputs to outputs if your data model for some reason requires a cell connected to each net. An industrial tool would hack in some workaround. I just delete the wire. Even large companies sometimes take a while to handle such cases. I regularly succeed to kill industrial grade synthesis tools with 0 input designs for example. There are VLSI placers that can not handle single cell designs, because the loop condition is checked after the loop. One element arrays in high level synthesis sometimes are fun, too. Another issue is, that many algorithms have a lot of tunable parameters that need to be adjusted for a whole range of devices for optimum results. The developer of the tool can do that on a case to case basis manually. But if you want to sell a push button solution to thousands of customers.... Still, there are many small companies that develop special case EDA algorithm implementations and sell them to tool chain vendors that incorporate them into their flows. A lot of what xilinx uses was not developed inhouse. Kolja SulimmaArticle: 93416
Before I start replying to people, I was just wondering, how is it
possible such that I can assign a high-impedence state to an output
using the code I wrote? Can I do it using the same number of inputs,
or do I have to add another input and implement it in this way..
always @(posedge clear)
out[index] <= z
or something like that?
Jason -
Yep, this did the trick, and managed to piss me off at the same time.
I don't see how this code is logically any different from the code that
I posted! Several people posted about hints and priorities for
coding, but in my reading, I never came across references to these
things. Does anyone have any good pointers or references?
Ray -
Is it acceptible to use asynchronous code in fpga's/cpld's if you are
going to be working at very low speeds? I'm not looking for a high
performance design, rather, a super-low-power deisgn that'll save me
pins on a microcontroller. I just want the ability to program one of
32 outputs using a minimal set of microcontroller pins.
With regards to switch bouncing, as it'll be switched from a
microcontroller, I dont have to deal with debounce, right?
Finally, I'm not sure what the reset/startup up hazards are -- I'll do
some googling after I post this. The reset I use is just to reset the
counter to zero. Will this be problematic?
Andy -
Thanks for the hint about the falling edge of the enable pin. Can you
provide me with some some pointers as to why this behaviour is the way
it is - or a starting point when I'm going through the manual.
This behaviour makes no logical sense again, just as this notion of
having to fllow templates and priorities. Is there any benefit for
such a strict structure? If a reset is higher in priority, why doesn't
the compiler/synthesizer just take care of it. Why not just give me a
warning rather than a hard error.
I also checked my course schedule, and there are not classes called
Digital Electronic Design or anything like that. What material would
such a course cover? Also, the project can't wait. If it can't be
done in a CPLD, we'll have to do it using either a larger
microcontroller or discrete multiplexers/counters. We're building an
implantable wireless neural recording device to record and transmit
data from a 32 channel probe, and the key factors are size and power
consuption (in that order). The entire device should be no bigger than
two quarters stacked on top of each other - which is why I wanted to go
with a CPLD rather than a large microcontroller or several discrete
components.
Thanks everyone for your help so far!
Reza
Article: 93417Peter Alfke wrote: > Marco, I am sure that you will not find anything beyond very basic > tutorial information. > These are the "crown jewels" of any FPGA company, and these jewels are > well guarded, but also polished daily. The quality of these tools > determines the success of our companies, and each of us wants to be at > leats a step ahead of the other company. > BTW, the continuous investment by companies like Xilinx and Altera (to > name just the two biggest) is enormous, and it is unlikely that an > individual engineer can provide significant improvements. Unless you > are a genius and addressthe problem in a very unconventioanl way. > Peter Alfke If these are so polished, then why do manual tools like PlanAhead, still give significant gains ? Until the automated tools get within a few % of good manual design, to me that demonstrates ample scope for improved SW. There also seem to be steady annual claims of Tool Improvements well into the double digits, which also suggest these are far from mastered ( or are these claims more inflated by marketing fluff... ?) A cynic might also point out, that the PlanAhead tools are $$$, and so Xilinx have something of a conflict of interest - if the free tools, get too close to the fullsuite, their revenue stream will drop.... -jgArticle: 93418
Reza Naima wrote: > Before I start replying to people, I was just wondering, how is it > possible such that I can assign a high-impedence state to an output > using the code I wrote? Can I do it using the same number of inputs, > or do I have to add another input and implement it in this way.. > > always @(posedge clear) > out[index] <= z > > or something like that? I guess that depends on whether you're trying to tri-state an output pad from the FGPA itself or an internal node. Are you trying to create a tri-state bus WITHIN the FPGA? I've never tried to synthesize something like that but I guess you'd have to use the 'z' constant. Never tried it. If you're tristating an output I'd expect a tri-state enable connection to the pad itself. That will be much more tool specific. > Yep, this did the trick, and managed to piss me off at the same time. > I don't see how this code is logically any different from the code that > I posted! Several people posted about hints and priorities for > coding, but in my reading, I never came across references to these > things. Does anyone have any good pointers or references? > Well, synthesis tools usually infer priority to if-else constructs. Now, you can argue that with a single condition to the 'if-else' that neither block has higher priority. But with nested trees of if-else's there is a definite priority. So the synthesizer has to map the code to cells existing in the FPGA. With an asynchronous reset to a FF it's really a level sensitive input. Anytime that the reset is asserted the output should be driven to the reset state. Might not seem like a level sensitive input, but it is. If 'posedge clk' occurs it should not be able to set the outputs, hence the highest priority portion of the 'if' structure is the comparision against the asynchronous reset. But the way that you had it written it had the non-reset case as the highest priority in the if-else statement. I've argued in the past with people that there is NO priority for a simple two segment if-else since there is no nesting of branches, but it's kinda semantic. > This behaviour makes no logical sense again, just as this notion of > having to fllow templates and priorities. Is there any benefit for > such a strict structure? If a reset is higher in priority, why doesn't > the compiler/synthesizer just take care of it. Why not just give me a > warning rather than a hard error. One of the issues is that you're not creating new base cells. Just mapping to existing ones. As for the 'template' type aspect, it's a matter of strict logical correctness. If it can't map the behaviour that you've specified to an existing cell, what else can it do? Also, don't forget that someone had to code the synthesizer :->Article: 93419
jg, I'll probably regret putting in my 2 cents, but here goes: It is true that "significant gains" are still (often, not always) realized by some careful hand placement, and some careful partitioning. That suggests that the design languages lack something important, as the intent of the designer is not being communicated to the tools. Teasing that intent from the HDL, through clever constrains, additional tools (like PlanAhead), or inferring (or evwen guessing) by use of clever code, can provide improvement. The software folks here at Xilinx are amazing: they have managed to improve every generation the performance while reducing the time to compile the designs; all the while we in IC design follow Moore's law and double the density. Not to mention we add more custom IP, and customers are getting more demanding. It matters little if IC Design or software cleverness led to low power, and high speed/performance. It is the sum total that is magic: the next version of the part (and the tools) provides that cost/benefit that is required for a new generation of applications. So, if I would recap this ramble: HDLs are not good at telling the tools the best way to actually do what the designer wanted. Lots of room for improvements here. Tools still have cleverness left to discover, as we seem to still be getting more clever even after 7 products (that I was personally involved in). Adjuct tools (like PlanAhead) are very valuable for the users who just must get the absolute best from the tools (without hiring a consultant who hand places, and tries to tease the performance out which is not always successful, and certainly can't be predicted), and because they are so useful, they provide direct benefit that is worth something (so they justify their price). Finally, it is the combination of tools and silicon that solves the problem, neither stands alone. AustinArticle: 93420
Hi John, Sorry for the delay in responding. I am not sure about what you mean by overlapping logic terms. By consensus term I mean use of the expression - ab + a'c = ab + a'c + bc. In this case, bc is the consensus term. As you probably know, bc prevents any glitches in the output when a changes. So what I am implying is that the switching activity on the output is reduced if we use the bc term. Thanks. -sanjayArticle: 93421
Thanks for your help! I think a 74LX1G126 will work with +/- 24mA sink & 10ns/V rise/fall time.Article: 93422
Ray Andraka wrote: > Asynchronous logic does not belong in FPGAs. They are not designed > for it and the tools don't support it (especially static timing > analysis). I recently needed a data path with a 56-bit adder/subtractor with binary and BCD modes. I thought I might have to pipeline it, but was pleasantly surprised that the Xilinx tools did a very good job with it as purely combinatorial logic. The inputs come from a mux from one of five registers or a few other sources, and the outputs can be loaded into any of four registers. As an additional complication, the arithmetic operation may be performed on any subrange of four-bit digits of the 56-bit word, which means that there is a 14:1 mux for carry out, and 2:1 muxes in the carry of each digit. I designed a four-bit slice using three ripple-carry adders: one to generate the one's or nine's complement of the subtrahend, one for the binary addition, and one for the for the BCD correction of the result. For each digit, I use two of those slices, one with the carry-in tied high, and one with it tied low. The carry outs of those act as the generate and propogate outputs for a carry lookahead scheme. And the data outputs feed a multiplexer selected by the carry-in computed by the lookahead carry logic, so they act as carry-select adders. When I set the mapper to use timing-directed mapping, and the PAR to high effort, ISE 8.1i was able to reduce it to ten levels of logic (including the input muxing), and static timing analysis says it will run with under 20 ns clock cycle in an XC3S1000-4 (the slower speed grade). I was not expecting the tools to be able to optimize it this well, especially as synthesis translated the carry-lookahead code, which I'd carefully written describing very flat logic, into a thirteen-deep tree. But apparently the mapper and PAR were smart enough to flatten it again. The static timing analysis had to analyze an immense number of paths. But I don't have any feedback loops in the logic, so I guess analysis of it isn't particularly difficult, just a large combinatorial problem. A pipelined design would probably achieve better throughput, but worse latency, and for my purposes latency was important. I'm not very experienced with complex data path and arithmetic design, so perhaps there are more efficient ways to implement a binary/BCD add/subtract slice, but even so I don't expect that it's possible to reduce the number of levels of logic of the purely combinatorial approach much.Article: 93423
I'm trying to get a tri-state output ([31:0] out). Any idea how to implement it? Thnx, Reza > I guess that depends on whether you're trying to tri-state an output pad from the FGPA itself or > an internal node. Are you trying to create a tri-state bus WITHIN the FPGA? I've never tried to > synthesize something like that but I guess you'd have to use the 'z' constant. Never tried it. > > If you're tristating an output I'd expect a tri-state enable connection to the pad itself. That > will be much more tool specific. >Article: 93424
Austin, > So, if I would recap this ramble: HDLs are not good at telling the > tools the best way to actually do what the designer wanted. The purpose of high level languages (for logic generation or writing software) is to allow cheaper programming, the loss factor I have witnessed has varied between 10 and >1000. If one has the resources to do things at a lower level, this is always the better choice. It does not take longer, it does not cost more text (except for very low complexity works where this is a non-issue anyway), it "only" takes more skills. No translating tool can replace direct access to the programmed hardware. I wish silicon vendors were less unwilling to allow third parties to be able to program their silicon, thus removing a major progress roadblock. But this is unlikely to come true, it has some political background which eludes me (economically the chip makers would benefit from such openness). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------
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