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
On 16/01/13 06:35, Jecel wrote: > On Tuesday, January 15, 2013 8:30:10 PM UTC-2, Andy wrote: >> Diff (in CVS) does a horrible job! Try something capable like >> BeyondCompare. Even the comparison capapilities in TortoiseSVN are >> better than CVS/diff (I have not tried tortoiseCVS, it may be very >> similar to tortoiseSVN). > > Thanks for the tip. I was talking about the diff tools normally found > in Linux. But my point was that while it is an easier problem to > solve for text than for graphics, it isn't always well done for text > and I hope I can get good results for graphics. For graphics or other binary files, you are entirely dependent on external programs. I know that Altium Designer has support for subversion, and can show differences between schematic versions quite well. And LibreOffice can be used to show differences between documents. But for many types of graphics there is no good way to show a difference. For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the same way as TortoiseSVN in Windows, and Meld as a good gui for comparing text files.Article: 154826
i was tryin to implement an ip core of multiplier on fpga spartan 3e,but in the synthesysing process it is showing some error about routing problems.Article: 154827
Can you describe the multiplier? (Width, anything special about it, does it use the multiplication operator) Is it using the embedded h/w multipliers in the s3e? What's the exact error message? JonArticle: 154828
On Jan 16, 6:30=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the > same way as TortoiseSVN in Windows, and Meld as a good gui for comparing > text files. Thanks for the pointers on linux tools. Did you mean "RabbitVCS"? RabbitVCS looks promising, but it is still version 0.15.1 (maybe a little immature yet for professional use, e.g. something we would deploy and recommend to the development teams). Meld looks really good, and appears a little more mature. AndyArticle: 154829
On Wed, 16 Jan 2013 08:30:49 -0800 (PST) Andy <jonesandy@comcast.net> wrote: > On Jan 16, 6:30=C2=A0am, David Brown <da...@westcontrol.removethisbit.com> > wrote: > > For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the > > same way as TortoiseSVN in Windows, and Meld as a good gui for comparing > > text files. >=20 > Thanks for the pointers on linux tools. Did you mean "RabbitVCS"? >=20 > RabbitVCS looks promising, but it is still version 0.15.1 (maybe a > little immature yet for professional use, e.g. something we would > deploy and recommend to the development teams). >=20 > Meld looks really good, and appears a little more mature. >=20 > Andy Rabbit's definitely a bit immature if you want to compare it to Tortoise. I find I still do half of my SVN management from the command line rather than using it; thinks like copying and status checking. I use meld as my visual diff tool, and it's absolutely great. --=20 Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154830
I'm not saying there are things you "can't" do in graphical entry, or that only text entry can do, just that there are lots of things that are (much) better done in text. When you are dealing with HDL issues, there is a standard of compliance (well, at least a workable one with VHDL), whereas there is no non-proprietary standard for graphical entry representations or file formats, except at the final output stage (an HDL). If my "source" is in some proprietary tool's format, and that tool goes away, it is extremely unlikely that any other tool will be able to use any of what I had relied upon as my "source". Which means I would be managing the machine-generated text as the "source" for successive modifications/versions of the product. I'll put well written, human-generated code up against machine-generated code (that's why we have coding standards) for understandability and maintainability any day of the week and twice on Sundays! On the other hand, as long at the graphical tool generates standard HDL, there are a lot of textual analysis tools that can still be employed on the results. The only difference is, they would not be dealing with the "source", and finding/translating and fixing issues found by analyzing the outputs of the graphical entry system is, if even possible, not usually nearly as straight-forward as when the analyzed text IS the source. Perhaps a different approach would be to use text as the source, and various tools to provide graphical representations (of different aspects) of the design for documentation to assist human analyses/ review (e.g. a hierarchy viewer, a state machine viewer, etc.) I find the visualization tools in the Syplify Pro HDL Analyst RTL view, especially with the ability to filter the output by several different criteria, to be extremely helpful in understanding how that downstream tool "sees" various aspects of my design. This is one of the reasons I prefer behavioral design descriptions rather than highly structural ones: there are tools that will show me the resulting structure from my behavioral descriptoin, but there are few tools that will show me the behavior (as other than simulation waveforms) from a highly strucural description. AndyArticle: 154831
>Checksum errors could very likely indicate an issue with the interface >timing, which includes clock to output of the FPGA, and setup/hold >time at FPGA inputs. Thank you Gabor for the reply. Good to know that it may be good way for my deliverance :) >You need to check the specs on your external device to calculate the >allowable setup and hold time at the FPGA. Then you need to add an >OFFSET IN BEFORE constraint to ensure that these conditions are met >by the design. For example if you determine that you have 3 ns setup >and 2 ns hold time with respect to the rising edge of the "clock" net: > >OFFSET = IN 3 ns VALID 5 ns BEFORE "clock" RISING ; > >This says that the valid data window starts 3 ns before the rising >edge of the clock input pin, and stays valid for 5 ns - that is until >2 ns after the rising edge of clock. > >You can also constrain the clock to output timing like: > >OFFSET = OUT 5 ns AFTER "clock" RISING; > >This sets a maximum delay from the clock input pin to an output pad. >Note that there is no way to constrain a minimum delay, so if you >are using source-synchronous logic, you need to be sure that output >timing is met by design. Normally this means placing output flops >in the IOB and using a DDR output register for the clock running >on a different phase from the data to allow hold time if necessary. > >-- Gabor Here is fragment of external device documentation: graph: http://uppix.net/8/5/1/151d221e03dbb2b8414340f3f08f6.png values: http://uppix.net/7/0/6/e5514ee21a32972ee177d6a0787b4.jpg For data transfer from external device to FPGA: If todly has max. 14 ns from last clock rising edge, then it has 6 ns setup time? And toh has min. 2.5 ns. Then I should set (if only fraction is possible): OFFSET = IN 6 ns VALID 8.5 ns BEFORE "clock" RISING ; ? For data transfer from FPGA to external device, which cause my problem: This part I don't understand. In that constraint should be external device inputhold time? Then: OFFSET = OUT 2 ns AFTER "clock" RISING; And that part about timing requirements. Placing output flops in IOB is just assigning signal which I want to send out to the output pin? Like here (data3_out is an output port): data3_out <= data_byte(3); And somehow use that DDR to allow 2 ns (again?) hold time? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154832
>And that part about timing requirements. Placing output flops in IOB is >just assigning signal which I want to send out to the output pin? Like here >(data3_out is an output port): > >data3_out <= data_byte(3); I see that placing registers into IOB is something what I should set. And I read that I can do it for all I/O registers in "Map properties" or just for selected registers in *.vhd file: attribute IOB : string attribute IOB of data3_out: signal is "TRUE"; Is that correct (data3_out is an output port)? I saw also that it is possible in *.ucf file, but don't know how to do it with port name usage. And it is for using the nearest logic to the output pad, what ensures the lowest setup time, correctly understand? If yes, then I suppose that the time between that register in IOB and next connected register may be increased. But I guess that I/O times are more important. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154833
On 16/01/13 18:19, Rob Gaddi wrote: > On Wed, 16 Jan 2013 08:30:49 -0800 (PST) > Andy <jonesandy@comcast.net> wrote: > >> On Jan 16, 6:30 am, David Brown <da...@westcontrol.removethisbit.com> >> wrote: >>> For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the >>> same way as TortoiseSVN in Windows, and Meld as a good gui for comparing >>> text files. >> >> Thanks for the pointers on linux tools. Did you mean "RabbitVCS"? >> >> RabbitVCS looks promising, but it is still version 0.15.1 (maybe a >> little immature yet for professional use, e.g. something we would >> deploy and recommend to the development teams). >> >> Meld looks really good, and appears a little more mature. >> >> Andy > > Rabbit's definitely a bit immature if you want to compare it to > Tortoise. I find I still do half of my SVN management from the command > line rather than using it; thinks like copying and status checking. > > I use meld as my visual diff tool, and it's absolutely great. > Rabbit does not have as many features as Tortoise, but don't be put off by the version number. Many programs and projects are fully usable despite low version numbers - while others use high version numbers for their initial releases. I find Rabbit more reliable than Tortoise at getting the overlay icons correct, but maybe that's just Nautilus being more consistent and accurate than Windows Explorer. But there is no doubt that Tortoise has lots more useful subversion features. I also do much of my subversion stuff from the command line, both in Windows and Linux - and also some from within programs with svn support (such as Eclipse). But Rabbit and Tortoise are very good for quickly viewing the state of files, as well as getting logs and differences.Article: 154834
On Mon, 14 Jan 2013 22:54:53 -0700, Rob Doyle wrote: > I creating an FPGA implementation of a old DEC PDP-10 (KS-10, > specifically) Mainframe Computer. Why? Because I always wanted one... > > The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. > At this stage, most of the instruction set diagnostics simulate > correctly. > > When I synthesize this design using Xilinx ISE I get warnings about > combinatorial loops involving the ALU - and an associated "Minimum > period: 656.595ns (Maximum Frequency: 1.523MHz)" message... > What should I do? Look at the critical path reported by synthesis. Sounds like a VHDL coding error; that delay would equate to a chain of 3-400 LUTs between FFs which strongly suggests a mistake somewhere. - BrianArticle: 154835
On Wednesday, January 16, 2013 7:43:41 AM UTC-8, Jon wrote: > Can you describe the multiplier? (Width, anything special about it, does it use the multiplication operator) > > > > Is it using the embedded h/w multipliers in the s3e? What's the exact error message? > > > > Jon I used the ip core of multiplier which is available in xilinx 12.2,then in the next step i assigned pins in the plan ahead.after that when i synthesised it gave these warnings: WARNING:Xst:647 - Input <clk> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. WARNING:Xst:647 - Input <a> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. WARNING:Xst:647 - Input <b> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. WARNING:Xst:1306 - Output <p> is never assigned. , Basically i wanted to learn how to implement an ip core on fpga kit, i will be very thankful for any kind of help! thanks.Article: 154836
On Thursday, January 17, 2013 4:32:18 AM UTC-8, deepak wrote: > On Wednesday, January 16, 2013 7:43:41 AM UTC-8, Jon wrote: > > > Can you describe the multiplier? (Width, anything special about it, does it use the multiplication operator) > > > > > > > > > > > > Is it using the embedded h/w multipliers in the s3e? What's the exact error message? > > > > > > > > > > > > Jon > > > > I used the ip core of multiplier which is available in xilinx 12.2,then in the next step i assigned pins in the plan ahead.after that when i synthesised it gave these warnings: > > WARNING:Xst:647 - Input <clk> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. > > WARNING:Xst:647 - Input <a> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. > > WARNING:Xst:647 - Input <b> is never used. This port will be preserved and left unconnected if it belongs to a top-level block or it belongs to a sub-block and the hierarchy of this sub-block is preserved. > > WARNING:Xst:1306 - Output <p> is never assigned. > > , > > Basically i wanted to learn how to implement an ip core on fpga kit, > > i will be very thankful for any kind of help! > > thanks. i was using a 2bit inputArticle: 154837
pavel.m wrote: >> Checksum errors could very likely indicate an issue with the interface >> timing, which includes clock to output of the FPGA, and setup/hold >> time at FPGA inputs. > > Thank you Gabor for the reply. > Good to know that it may be good way for my deliverance :) > >> You need to check the specs on your external device to calculate the >> allowable setup and hold time at the FPGA. Then you need to add an >> OFFSET IN BEFORE constraint to ensure that these conditions are met >> by the design. For example if you determine that you have 3 ns setup >> and 2 ns hold time with respect to the rising edge of the "clock" net: >> >> OFFSET = IN 3 ns VALID 5 ns BEFORE "clock" RISING ; >> >> This says that the valid data window starts 3 ns before the rising >> edge of the clock input pin, and stays valid for 5 ns - that is until >> 2 ns after the rising edge of clock. >> >> You can also constrain the clock to output timing like: >> >> OFFSET = OUT 5 ns AFTER "clock" RISING; >> >> This sets a maximum delay from the clock input pin to an output pad. >> Note that there is no way to constrain a minimum delay, so if you >> are using source-synchronous logic, you need to be sure that output >> timing is met by design. Normally this means placing output flops >> in the IOB and using a DDR output register for the clock running >> on a different phase from the data to allow hold time if necessary. >> >> -- Gabor > > Here is fragment of external device documentation: > graph: http://uppix.net/8/5/1/151d221e03dbb2b8414340f3f08f6.png > values: http://uppix.net/7/0/6/e5514ee21a32972ee177d6a0787b4.jpg > > For data transfer from external device to FPGA: > If todly has max. 14 ns from last clock rising edge, then it has 6 ns setup > time? And toh has min. 2.5 ns. Then I should set (if only fraction is > possible): > > OFFSET = IN 6 ns VALID 8.5 ns BEFORE "clock" RISING ; > This would be correct if the clock input to both devices arrives at the device input pin at the same time (i.e. a typical radial clock distribution network like PCI bus) and the clock period is 20 ns. > ? > > For data transfer from FPGA to external device, which cause my problem: > This part I don't understand. In that constraint should be external device > inputhold time? Then: > > OFFSET = OUT 2 ns AFTER "clock" RISING; No. The OFFSET OUT constrains the *maximum* time from the clock pin to the data output. This really affects the setup time at the external device and should be set to the clock period minus the setup requirement (again assuming a radial clock distribution). The hold time at the external device needs to be met by design, either due to the absolute minimum guaranteed delay from clock to output on the FPGA, or by using a phase-shifted clock. On the other hand, if you don't have a radial clocking scheme, you need to also deal with the difference in clock arrival time (clock skew) between the FPGA and the external device. And in all instances you should also factor in the board-level propagation delay due to trace lengths. These become more important at higher clock frequencies (for setup time) but are always importantant for hold time regardless of the clock frequency. > > And that part about timing requirements. Placing output flops in IOB is > just assigning signal which I want to send out to the output pin? Like here > (data3_out is an output port): > > data3_out <= data_byte(3); > > And somehow use that DDR to allow 2 ns (again?) hold time? > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 154838
pavel.m wrote: >> And that part about timing requirements. Placing output flops in IOB is >> just assigning signal which I want to send out to the output pin? Like > here >> (data3_out is an output port): >> >> data3_out <= data_byte(3); > > I see that placing registers into IOB is something what I should set. > And I read that I can do it for all I/O registers in "Map properties" or > just for selected registers in *.vhd file: > > attribute IOB : string > attribute IOB of data3_out: signal is "TRUE"; > > Is that correct (data3_out is an output port)? I believe the proper element to apply the IOB constraint to is the actual register that drives the output. So if data3_out is just a continous assign to data_byte(3) and data_byte(3) is assigned in a clocked process, then data_byte(3) should have the IOB = TRUE attribute. You could also globally push registers into the IOB, but that may affect your ability to meet internal timing. > I saw also that it is possible in *.ucf file, but don't know how to do it > with port name usage. > > And it is for using the nearest logic to the output pad, what ensures the > lowest setup time, correctly understand? If yes, then I suppose that the > time between that register in IOB and next connected register may be > increased. But I guess that I/O times are more important. > Actually meeting the timing constraints is most important. If you only need to guarantee a certain input setup and clock to output timing, then you can leave the global IOB setting at "auto" and let the tools decide where to place the registers in order to balance internal and external timing requirements. On the otehr hand, if you have to keep interface skew to a minimum (as in a source-synchronous design) then you will need to push registers in the IOB, because the constraints only control maximum delay and not skew. > > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 154839
Dear Gabor,
first of all thank you for your patience.
Because I'm not sure about all of this and I feel that I'm not capable to
do it myself I have to give more details of my design:
- crystal clock-oscillator generates single 50MHz clock, which comes into
FPGA,
- the process where I have to send data out uses rising_edge(clock)
instruction,
- there is FSM, where two states are used for sending data out, this is
because I use 4 lines for data output and I want to send bytes, so in one
state 4 MSB are sent, in second state 4 LSB are sent, something like this:
when WRITE_DATA_MSB =>
data3_out <= data_byte(3);
data2_out <= data_byte(2);
data1_out <= data_byte(1);
data0_out <= data_byte(0);
state <= WRITE_DATA_LSB;
when WRITE_DATA_LSB =>
data_byte <= some_new_value; --new data
state <= WRITE_DATA_MSB;
data3_out <= data_byte(7);
data2_out <= data_byte(6);
data1_out <= data_byte(5);
data0_out <= data_byte(4);
There is also condition in WRITE_DATA_MSB, when it should finish jumping
between these two states (when some amount of data bytes will be sent
out).
That "clock", which is used also for that process, must be sent to the
external device with data. Is that topology what you called
"Source-Synchronous" system? Then I think I should use what you recommend:
push registers in the IOB, because in that topology I want minimum skew.
And from what you said that registers should be:
attribute IOB : string
attribute IOB of data_byte: signal is "TRUE"; (corrected register name)
And for clock, I don't understand what is "radial clocking scheme". I
couldn't find it, but I suppose that it is not what I have, because I send
my 50 MHz clock from FPGA to the external device. So there is propagation
delay and other factors which cause that clock on which FPGA works and
clock on external device input pin are different. If these clocks would be
the same ("radial clocking") I could use:
OFFSET = IN 6 ns VALID 8.5 ns BEFORE "clock" RISING ; (as posted before)
OFFSET = OUT 14 ns AFTER "clock" RISING; [this is corrected: 20ns(clock
period) - 6ns(setup time requirement of external device)]
But I should somehow recalculate that values taking into account that
delays? How?
I suppose that should be here also Clock Forwarding technique applied for
clock sending...
Sorry that I ask also for the things that you described, but writing it in
my words and asking you if it is true make me sure that I something
understand or not. It is not easy subject and additional factor which makes
it harder to understand is that I'm not native english speaker.
Best regards,
Pavel
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 154840On 1/15/2013 12:54 AM, Rob Doyle wrote: > > I creating an FPGA implementation of a old DEC PDP-10 (KS-10, > specifically) Mainframe Computer. Why? Because I always wanted one... > > The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. > At this stage, most of the instruction set diagnostics simulate correctly. > > When I synthesize this design using Xilinx ISE I get warnings about > combinatorial loops involving the ALU - and an associated "Minimum > period: 656.595ns (Maximum Frequency: 1.523MHz)" message... > > My understanding is that if combination loops really existed then the > simulation wouldn't stabilize. I can't really add pipelining or > registers to the design without affecting the microcode - and I don't > want to do that. > > Most of the information that I've read about "false paths" assume two > clocked processes not a combinatorial loop. > > Anyway. I'm not sure how to resolve this. I can mark the path as a > false path but I think that it will ignore /all/ the timing (even the > desired timing) through that path. > > What should I do? > > Rob. I took a look at the block diagram and I don't see any combinatorial loops. However, they use latches for the RAM outputs. These are combinatorial if implemented that way. Typically latches are used because they can provide speed advantages since the data will flow through before being held while D type registers don't change outputs until the clock edge. Are the RAM and output latches in the path being reported as too long? If so, I would recommend changing the latches to rising edge registers. This should cut these loops. The RAM is level sensitive which may be a problem in an FPGA. I think all of the sequential elements are edge sensitive these days. I supposed you could make it out of latches; it's not that many elements. The clock runs down the center of the block diagram cutting the data paths and preventing any internal loops I can see. Of course, there could be combinatorial loops created by the way it is used. The only one I see is created if you loop the ALU output Y back to the ALU input D. This could happen if you try to put these busses on a tri-state bus. Since tri-states aren't used in an FPGA, you are better off using multiple separate busses to drive all the various inputs hanging on the tri-state bus. I think it would be very interesting to implement this in a low power FPGA and see just how efficient it can become. What target were you thinking of? I am currently working with the iCE40 family from Lattice and it has very impressive power consumption. You likely could run a design at some 10's of MHz while drawing the power level of an LED... a small LED. Any interest in making this a group project? Or are you keeping all the fun to yourself? BTW, where did you get documentation on the PDP-10 sufficient to design an equivalent? Just from the instruction manual? Or do you have more details? RickArticle: 154841
rickman <gnuarm@gmail.com> wrote: > On 1/15/2013 12:54 AM, Rob Doyle wrote: >> I creating an FPGA implementation of a old DEC PDP-10 (KS-10, >> specifically) Mainframe Computer. Why? Because I always wanted one... >> The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. >> At this stage, most of the instruction set diagnostics simulate correctly. >> When I synthesize this design using Xilinx ISE I get warnings about >> combinatorial loops involving the ALU - and an associated "Minimum >> period: 656.595ns (Maximum Frequency: 1.523MHz)" message... >> My understanding is that if combination loops really existed then the >> simulation wouldn't stabilize. I can't really add pipelining or >> registers to the design without affecting the microcode - and I don't >> want to do that. Loops with an odd number of inversions won't stabilize, but with an even number they should be fine. (snip) > I took a look at the block diagram and I don't see any combinatorial > loops. However, they use latches for the RAM outputs. These are > combinatorial if implemented that way. Typically latches are used > because they can provide speed advantages since the data will flow > through before being held while D type registers don't change outputs > until the clock edge. The tools should be good enough to figure out latches. As I wrote above, though, be sure that there is no (odd number) of inverters in the loop. > Are the RAM and output latches in the path being reported as too long? > If so, I would recommend changing the latches to rising edge registers. > This should cut these loops. The RAM is level sensitive which may be > a problem in an FPGA. I think all of the sequential elements are edge > sensitive these days. I supposed you could make it out of latches; it's > not that many elements. The BRAM on most FPGAs are synchronous (clocked). That might not match what you need for some older designs. If it isn't too big, and you really need asynchronous RAM, you have to make it out of CLB logic. > The clock runs down the center of the block diagram cutting the data > paths and preventing any internal loops I can see. Of course, there > could be combinatorial loops created by the way it is used. The only > one I see is created if you loop the ALU output Y back to the ALU input > D. This could happen if you try to put these busses on a tri-state bus. > Since tri-states aren't used in an FPGA, you are better off using > multiple separate busses to drive all the various inputs hanging on the > tri-state bus. As I understand it, the Xilinx tools, at least, know how to convert tristate logic to MUX logic. I suppose in some cases that might generate unexpected, or even false, loops. I believe that the KA-10 was done in asynchronous (non-clocked) logic. That might make an interesting FPGA project. -- glenArticle: 154842
You might be able to get around the async/sync ram issues by using the other edge of your clock (and if necessary, a dual-port bram could run off different edges for read & write). There are also ways to build a DDR register out of two registers and 3 XOR (or XNOR) gates, without gating the clock. Google "flancter circuit". It is STA-friendly too. That might be another trick you could use. If the loops were not stable, it would show up even in RTL sim (assuming the conditions needed to make it unstable were met). Since it works with the loops in there (in simulation), I assume it is at least not always unstable. AndyArticle: 154843
On 1/17/2013 3:49 PM, glen herrmannsfeldt wrote: > rickman<gnuarm@gmail.com> wrote: >> On 1/15/2013 12:54 AM, Rob Doyle wrote: > >>> I creating an FPGA implementation of a old DEC PDP-10 (KS-10, >>> specifically) Mainframe Computer. Why? Because I always wanted one... > >>> The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU. >>> At this stage, most of the instruction set diagnostics simulate correctly. > >>> When I synthesize this design using Xilinx ISE I get warnings about >>> combinatorial loops involving the ALU - and an associated "Minimum >>> period: 656.595ns (Maximum Frequency: 1.523MHz)" message... > >>> My understanding is that if combination loops really existed then the >>> simulation wouldn't stabilize. I can't really add pipelining or >>> registers to the design without affecting the microcode - and I don't >>> want to do that. > > Loops with an odd number of inversions won't stabilize, but with an > even number they should be fine. > > (snip) > >> I took a look at the block diagram and I don't see any combinatorial >> loops. However, they use latches for the RAM outputs. These are >> combinatorial if implemented that way. Typically latches are used >> because they can provide speed advantages since the data will flow >> through before being held while D type registers don't change outputs >> until the clock edge. > > The tools should be good enough to figure out latches. Figure out in what context? The tool can't know when the latch is enabled or disabled. When enabled it is transparent and so is logic. I'm not sure what your point is. For timing a latch is combinational logic and has to be figured into the timing paths. In fact, that is usually why latches are used, because they improve timing. > As I wrote above, though, be sure that there is no (odd number) > of inverters in the loop. > >> Are the RAM and output latches in the path being reported as too long? >> If so, I would recommend changing the latches to rising edge registers. >> This should cut these loops. The RAM is level sensitive which may be >> a problem in an FPGA. I think all of the sequential elements are edge >> sensitive these days. I supposed you could make it out of latches; it's >> not that many elements. > > The BRAM on most FPGAs are synchronous (clocked). That might not > match what you need for some older designs. If it isn't too big, > and you really need asynchronous RAM, you have to make it out > of CLB logic. Yes, not only are the block RAMs synchronous, the LUT RAMs (distributed) are also synchronous. That is why I say you have to make async RAM out of latches. >> The clock runs down the center of the block diagram cutting the data >> paths and preventing any internal loops I can see. Of course, there >> could be combinatorial loops created by the way it is used. The only >> one I see is created if you loop the ALU output Y back to the ALU input >> D. This could happen if you try to put these busses on a tri-state bus. >> Since tri-states aren't used in an FPGA, you are better off using >> multiple separate busses to drive all the various inputs hanging on the >> tri-state bus. > > As I understand it, the Xilinx tools, at least, know how to convert > tristate logic to MUX logic. I suppose in some cases that might > generate unexpected, or even false, loops. That should not create loops unless the loop is already there in the connected logic. Translating tristate busses create multiple sets of multiplexors which are all distinct, preventing loops... unless the rest of the logic connects input to output. > I believe that the KA-10 was done in asynchronous (non-clocked) logic. > That might make an interesting FPGA project. Doing async logic in an FPGA is not so easy. You need timing info that is hard to get. RickArticle: 154844
On 1/15/2013 7:21 PM, rickman wrote: > On 1/15/2013 12:54 AM, Rob Doyle wrote: >> >> I creating an FPGA implementation of a old DEC PDP-10 (KS-10, >> specifically) Mainframe Computer. Why? Because I always wanted >> one... >> >> The KS-10 was microcoded and used 10x am2901 4-bit slices in the >> ALU. At this stage, most of the instruction set diagnostics >> simulate correctly. >> >> When I synthesize this design using Xilinx ISE I get warnings >> about combinatorial loops involving the ALU - and an associated >> "Minimum period: 656.595ns (Maximum Frequency: 1.523MHz)" >> message... >> >> My understanding is that if combination loops really existed then >> the simulation wouldn't stabilize. I can't really add pipelining >> or registers to the design without affecting the microcode - and I >> don't want to do that. >> >> Most of the information that I've read about "false paths" assume >> two clocked processes not a combinatorial loop. >> >> Anyway. I'm not sure how to resolve this. I can mark the path as a >> false path but I think that it will ignore /all/ the timing (even >> the desired timing) through that path. >> >> What should I do? > > Do you know why the tool is complaining? Did you write the code > describing the ALU? Off the top of my head, I can't think of why an > ALU would have a combinatorial loop. It should have two input data > busses, a number of control inputs, an output data bus and some > output status signals. Oops. Sorry I guess I relied to rickman instead of following up with the group. I'm resending... I guess I'm using term ALU and am2901 interchangeably. I'll be more specific. There is nothing wrong with the am2901 proper. It is what it is. > I don't recall the details of the 2901 bit slice and my data books > are not handy. That's the problem with paper books, you can't just > shove them on your hard drive... Does this part have an internal > register file? Even so, that means the part would have a clock and > not a combinatorial loop. > Maybe this is because of some internal bus that is shared in a way > that looks like a loop even though it would never be used that way? Exactly. The problems is that am2901 output goes to a bus that eventually routes back to the am2901 input for some unused (as best I can tell) configuration of the microcode. This all happens with no registers in the loop. The am2901 does have an internal dual-ported register file. Register file writes from the ALU output are clocked. Register file reads to the ALU input are latched only. The am2901 control inputs and register file addresses all originate from the microcode which is registered. The am2901 has a single input bus which is combinatorial through the ALU to output bus. Therefore all am2901 ops require at least one register (or the constant zero) as an ALU source. I think I know what to do. It looks like ISE supports a FROM-THRU-THRU-THRU-THRU-TO timing constraint - with an indefinite number of THRUs. I think I just want to very specifically exclude the paths that the tool is whining about and leave everything else. > I may have to find my old AMD data book. That could be an > archeological dig! I guess that it is just a design from another day - a whole lot less synchronous than anything I've done in an FPGA before. I have enjoyed going back through that all. I even found my "Mick and Brick" book. I'll probably do a VAX 11/780 next which also used bit-sliced parts. Bob.Article: 154845
On 1/17/2013 1:03 PM, rickman wrote: > BTW, where did you get documentation on the PDP-10 sufficient to > design an equivalent? Just from the instruction manual? Or do you > have more details? Folks have done a remarkable job at archiving design information, software, and hardware for these historic machines. Notably Paul Allen (of Microsoft Fame) sponsors a museum that maintains a few of these machines in working order. See http://www.livingcomputermuseum.org/ The folks at bitsavers.org are frantically scanning documents/books and imaging magnetic media before it becomes unreadable. AMD Info is at: http://bitsavers.org/pdf/amd/ All the KS10/PDP10 information is at: http://bitsavers.org/pdf/dec/pdp10/KS10/ Microcode source/listings and processor diagnostics are available from: http://pdp-10.trailing-edge.com/klad_sources/index.html A webpage that describes my/our project is at: http://www.techtravels.org/KS10FPGA/ I put a block diagram of the KS10 CPU on the techtravels website. Referring to that block diagram, the false paths are from the ALU output through the DBM mux, through the DBUS Mux, and back into the ALU. There is another false path though the SCAD. (The SCAD is a 12-bit mini-ALU built from 3x 74S181s that is used for managing floating-point exponents and loop constructs in the microcode). > Any interest in making this a group project? Or are you keeping all > the fun to yourself? This is definitely a group project. Right now, I'm doing all the FPGA work by myself - If you are interested in participating, contact me off-list. You used the term 'archeology'. It sure feels like that... Rob.Article: 154846
Rob Doyle <radioengr@gmail.com> wrote: (snip) > I guess I'm using term ALU and am2901 interchangeably. > I'll be more specific. > There is nothing wrong with the am2901 proper. It is what it is. I suppose, but it was designed way before the tools we use now. (snip) > The problems is that am2901 output goes to a bus that eventually routes > back to the am2901 input for some unused (as best I can tell) > configuration of the microcode. This all happens with no registers in > the loop. (snip) > I guess that it is just a design from another day - a whole lot less > synchronous than anything I've done in an FPGA before. > I have enjoyed going back through that all. I even found my "Mick and > Brick" book. I'll probably do a VAX 11/780 next which also used > bit-sliced parts. Years ago, maybe just about when it was new, I bought "Mick and Brick." Then, about 20 years ago, it got lost in a move. A few weeks ago I bought a used one from half.com for a low price. (In case I decide to do some 2901 designs in FPGAs.) The discussion on combinatorial loops reminds me of the wrap around carry on ones complement adders. If done the obvious way, it is a combinatorial loop, but hopefully one that, in actual use, resolves itself. -- glenArticle: 154847
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> The BRAM on most FPGAs are synchronous (clocked). That might not >> match what you need for some older designs. If it isn't too big, >> and you really need asynchronous RAM, you have to make it out >> of CLB logic. > Yes, not only are the block RAMs synchronous, the LUT RAMs (distributed) > are also synchronous. That is why I say you have to make async RAM out > of latches. The are now? They didn't used to be. I am somewhat behind in the generations of FPGAs. (snip, I also wrote) >> I believe that the KA-10 was done in asynchronous (non-clocked) logic. >> That might make an interesting FPGA project. > Doing async logic in an FPGA is not so easy. You need timing info that > is hard to get. The whole idea behind asynchronous logic is that you don't need to know any timing information. Otherwise known as self-timed logic, there is enough hand-shaking such that every signal changes when it is ready, no sooner and no later. If you use dual-rail logic: http://en.wikipedia.org/wiki/Asynchronous_system#Asynchronous_datapaths then all timing just works. If you mix synchronous and asynchronous logic, then things get more interesting. -- glenArticle: 154848
Hi to everyone! This is my first message here so first of all thanks to everyone to let me post here! I have a homework, it consists on writing a processor and make it work in a Spartan 3. I did the first but the second one is getting difficult. I just want to show my profesor that processor is working well so I want to generate a clock event with a button or switch just like here: http://fpgawiki.dustingram.com/index.php?title=Button_Clock My UCF is this one: #PACE: Start of Constraints generated by PACE NET "act_reg3" CLOCK_DEDICATED_ROUTE = FALSE; #PACE: Start of PACE I/O Pin Assignments NET "an0" LOC = "E13" ; NET "an3" LOC = "F14" ; NET "an2" LOC = "G14" ; NET "an1" LOC = "d14" ; #This is a button to simulate a clock NET "simulated_clk" LOC = "M13" ; ######################### 8 Leds ########################################### NET "mult_lec" LOC = "K12" ; NET "mult_esc" LOC = "P14" ; NET "mult_ret" LOC = "L12" ; NET "mult_pc" LOC = "N14" ; NET "reg_w" LOC = "P13" ; NET "call_w" LOC = "N12" ; NET "sel_alu" LOC = "P12" ; #I use this for another thing NET "clk" LOC = "T9" ; ###################################### Segments ########################################## NET "segmentos<6>" LOC = "E14" ; NET "segmentos<5>" LOC = "G13" ; NET "segmentos<4>" LOC = "N15" ; NET "segmentos<3>" LOC = "P15" ; NET "segmentos<2>" LOC = "R16" ; NET "segmentos<1>" LOC = "F13" ; NET "segmentos<0>" LOC = "N16" ; NET "segmentos<7>" LOC = "P16" ; ####################################### Switches ########################################### NET "act_reg1" LOC = "F12" ; NET "act_reg2" LOC = "G12" ; NET "act_reg3" LOC = "H14" ; #PACE: Start of PACE Area Constraints #PACE: Start of PACE Prohibit Constraints #PACE: End of Constraints generated by PACE ------------------------------------------------------------------- And here is a fragment of my processor: ----PC process process(inicio,simulated_clk) variable pc_out: std_logic_vector (15 downto 0); variable pc_high : std_logic_vector(15 downto 0); begin --Si es la primera vez que se carga if inicio='0' then pc<="0000000000000000"; reg_ret<="0000000000000000"; pc_out:="0000000000000000"; --Se ha cargado más veces elsif simulated='1' and simulated_clk'event then pc_out:=pc; ... end process; I don't know why it doesn't work. As I said I just want to simulate a clock so to show my proffesor how the processor works step by step (instruction by instruction). Hope you can help. Thanks! PD: Sorry for my poor English. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154849
Le 18/01/2013 21:32, tupadre a écrit :
> Hi to everyone!
[...]
> And here is a fragment of my processor:
>
> ----PC process
> process(inicio,simulated_clk)
>
> variable pc_out: std_logic_vector (15 downto 0);
> variable pc_high : std_logic_vector(15 downto 0);
> begin
> --Si es la primera vez que se carga
> if inicio='0' then
> pc<="0000000000000000";
> reg_ret<="0000000000000000";
> pc_out:="0000000000000000";
> --Se ha cargado más veces
> elsif simulated='1' and simulated_clk'event then
> pc_out:=pc;
>
> ...
> end process;
>
>
> I don't know why it doesn't work. As I said I just want to simulate a clock
> so to show my proffesor how the processor works step by step (instruction
> by instruction).
>
> Hope you can help. Thanks!
Hello
Your clock edge condition looks wrong, it should be :
elsif simulated_clk = '1' and simulated_clk'event then
or you can use the rising_edge function instead :
elsif rising_edge(simulated_clk) then
Nicolas
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