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
Tim Wescott <tim@seemywebsite.com> wrote: > Is there any way to do this? Give the Sourceforge-SVN version of xc3sprog a try. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 148451
On Sat, 24 Jul 2010 11:20:22 +0200, whygee wrote: > "another one bytes the dust"... > > According to Processor Watch - July 22, 2010 (sorry, I have no URL, it > was sent to me by email) > > ================================================ Tears for Tier Logic > By Tom R. Halfhill, Senior Editor, MPR (7/19/2010) > > FPGA startup Tier Logic looks doomed after failing to raise > enough money to move its first chips into production. A last-ditch > attempt to save the privately held company fell through last week, > said Paul Hollingworth, vice president for marketing and sales. > > Tier Logic, founded in Silicon Valley in March 2002, > has spent about $20 million from its first-round investors and needs > another $20 million to $30 million to bring its chips to market and > reach breakeven, he said. Matrix Partners, the sole remaining > investor, extended a bridge loan to keep Tier Logic alive for eight > months during the search for additional funding, but that money is > nearly gone, and the quest was unsuccessful. Another first-round > investor, Walden International, pulled out last year. > > Hollingworth said the situation is frustrating, because Tier > Logic has operational samples of its first programmable-logic chips > and has already taken orders from early customers. The company had > planned to begin production by the end of this quarter. > ================================================ > > Now, $20 to develop silicon over almost 8 years, that sounds quite > reasonable. So what did go wrong ? And what will happen now ? > > I think that now, the worse that could happen is that X & A buy all the > patent portfolio and reinfoce their dominance in the market... > > yg There is a much bigger problem, there is no VC money anymore especially for hardware and chip companies and there is no IPO market which is why there is no VC money.Article: 148452
On Jul 23, 7:22=A0pm, Andy Peters <goo...@latke.net> wrote: > On Jul 22, 9:50=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote: > > > What about more complicated cases such as the following > > inferred RAM, in which the bottom 7 bits of addr can always be used to > > address the RAM? > > > =A0 =A0 =A0if (addr < 128) then > > =A0 =A0 =A0 =A0 =A0dout <=3D RAM(addr); > > =A0 =A0 =A0else > > =A0 =A0 =A0 =A0 =A0dout <=3D (others =3D> '-'); > > =A0 =A0 =A0end if; > > Some hand-optimization might be good here: > > =A0 =A0 dout <=3D RAM(addr); > > After all, in this (likely contrived!) case, you don't care about the > assignment if the address is 128 or higher, so then not doing the > comparison at all and just doing the assignment anyway gives the best > result. > > A smart synthesis tool should do that optimization. > Not quite. As I mentioned in my earlier post, the way to write the code is dout <=3D ram(addr mod 128); If you just write "dout <=3D RAM(addr);" then a larger memory will be inferred. You're assuming that addr is not something 'big' like signal addr: natural range 0 to 1048575; -- 20 bits Kevin JenningsArticle: 148453
I've been looking at this some more. I don't see any technical hurdles to maintaining my Actel Cortex-M1 design in strait VHDL. The code that comes out of SmartDesign is standard structural VHDL that I can edit and modify with just a text editor. The only inconvenience is the text formatting. I think I will use a VHDL beautifier like the one that exists in emacs to clean up all the source. Then I will further clean up the resulting code as needed where I will be working. As I see it, there is no need to clean up parts of the source code that I am not modifying. Really the machine generated code that comes out of SmartDesign is pretty good. There are bad indentation and line breaks that can be cleaned up with a beautifier. Beyond that the only ugly thing is the port map assignments for busses. The port maps break out every single member of a bus and assign them individually. That really boosts the size of source code and hurts readability. I understand that the Cortex processor IP is a black box. I cannot get access to the Cortex processor internal source code and retarget it (without paying a lot of money). I just want to maintain the system VHDL using only a text editor. That looks to be entirely practical.Article: 148454
Hi everyone, Can someone kindly provide any good links/tutorials/articles for implementing weighted round robin (WRR) arbitration? Thank you. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148455
I mean implementation in hardware. Thanks. >Hi everyone, > >Can someone kindly provide any good links/tutorials/articles for >implementing weighted round robin (WRR) arbitration? > >Thank you. > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148456
Hi, Using Altera Model-Sim to do a gate level simulation. The .vo file that is produced doesn't seem to be modeling the internal RAM's correctly. In the design they are instantiated as 12bit but the EDA netlist has them as 4 bits. Any help on this? Has anyone experienced a similar problem? Regards, RobArticle: 148457
On Jul 24, 9:15=A0pm, Rob <noth...@nowhere.com> wrote: > Hi, > > Using Altera Model-Sim to do a gate level simulation. The .vo file that > is produced doesn't seem to be modeling the internal RAM's correctly. In > the design they are instantiated as 12bit but the EDA netlist has them > as 4 bits. > Answer these questions first: 1. Does the gate level simulation *results* not match the original sim *results*? 2. Are you questioning the validity of the .vo file based solely on a visual inspection of the .vo file? If you can only answer 'yes' to question #2, then go back to determine the answer to question #1 first. Since you say "doesn't seem to..." I'm guessing that question #1 hasn't been answered yet. > Any help on this? Has anyone experienced a similar problem? > I have had other cases where post-route sim was not correct because of incorrect synthesis from Quartus...not often, but at least two cases that I recall off the top of my head. If your answer to question #1 is that the post-route sim is not correct, then the method to fix it is... 1. Create a testbench with pre- and post-route simulation models both instantiated. Demonstrate that incorrect results are being generated. 2. Write up a description of how to run the sim and how the post-route sim differs 3. Submit your write up as a case to Altera 4. Start working on a hypothesis for what might be wrong and start developing some way to work around the bug. Steps 1 thru 3 help Altera improve Quartus which long term helps you and others. Step 4 helps you get your current design working. If instead your answer to question #2 is that the post-route sim is correct, then here are some possibilities: - Your testbench does not adequately exercise the memory in such a way that it results in any difference to any I/O pin. If so, then beef up the testbench to that level. - 8 of the output data bits from the memory are either not used, or connected to logic which ultimately does not connect to any output pin of the device. In short, those 8 bits were reduced out and not needed. - You're misinterpreting the .vo file in some fashion. Maybe there are three 4 bit memories instantiated in the actual implementation. Kevin JenningsArticle: 148458
On Jul 24, 11:23=A0am, "onkars" <onkars@n_o_s_p_a_m.n_o_s_p_a_m.winlab.rutgers.edu> wrote: > Hi everyone, > > Can someone kindly provide any good links/tutorials/articles for > implementing weighted round robin (WRR) arbitration? > http://www.lmgtfy.com/?q=3Dweighted+round+robin+arbitration > Thank you. =A0 =A0 =A0 =A0 > You're welcome KJArticle: 148459
I mis-read the .vo file. It is implementing the 12 bit ram as three 4-bit memories. Rob wrote: > Hi, > > Using Altera Model-Sim to do a gate level simulation. The .vo file that > is produced doesn't seem to be modeling the internal RAM's correctly. In > the design they are instantiated as 12bit but the EDA netlist has them > as 4 bits. > > Any help on this? Has anyone experienced a similar problem? > > Regards, > RobArticle: 148460
I read this post, just as I was coming back to the group to update my findings, which were as you also mention below. The 12 bit memory is instantiated as three 4-bit memories. Thanks, Rob KJ wrote: > On Jul 24, 9:15 pm, Rob <noth...@nowhere.com> wrote: >> Hi, >> >> Using Altera Model-Sim to do a gate level simulation. The .vo file that >> is produced doesn't seem to be modeling the internal RAM's correctly. In >> the design they are instantiated as 12bit but the EDA netlist has them >> as 4 bits. >> > > Answer these questions first: > 1. Does the gate level simulation *results* not match the original sim > *results*? > 2. Are you questioning the validity of the .vo file based solely on a > visual inspection of the .vo file? > > If you can only answer 'yes' to question #2, then go back to determine > the answer to question #1 first. Since you say "doesn't seem to..." > I'm guessing that question #1 hasn't been answered yet. > >> Any help on this? Has anyone experienced a similar problem? >> > I have had other cases where post-route sim was not correct because of > incorrect synthesis from Quartus...not often, but at least two cases > that I recall off the top of my head. > > If your answer to question #1 is that the post-route sim is not > correct, then the method to fix it is... > 1. Create a testbench with pre- and post-route simulation models both > instantiated. Demonstrate that incorrect results are being generated. > 2. Write up a description of how to run the sim and how the post-route > sim differs > 3. Submit your write up as a case to Altera > 4. Start working on a hypothesis for what might be wrong and start > developing some way to work around the bug. > > Steps 1 thru 3 help Altera improve Quartus which long term helps you > and others. Step 4 helps you get your current design working. > > If instead your answer to question #2 is that the post-route sim is > correct, then here are some possibilities: > - Your testbench does not adequately exercise the memory in such a way > that it results in any difference to any I/O pin. If so, then beef up > the testbench to that level. > - 8 of the output data bits from the memory are either not used, or > connected to logic which ultimately does not connect to any output pin > of the device. In short, those 8 bits were reduced out and not > needed. > - You're misinterpreting the .vo file in some fashion. Maybe there > are three 4 bit memories instantiated in the actual implementation. > > Kevin JenningsArticle: 148461
Hello, I'm also a linux user for most of my work. On the other hand, Windows is not that bad or expensive so I just dual boot. Actel is doing a great job for a smaller company by releasing their mainline development code as a linux version but some of the outlier tools, like FlashPro, are still Windows only as you mention. Lately I have been playing around with the Arm/Amba IP libraries for Actel FPGAs. I'm really impressed by what they get out there for free. The SoftConsole tool for writing the embedded C code is really practical and includes an integrated source code debugger that uses the FlashPro cable to access the On Chip Debug (OCD) hardware of the Arm processor. It is based on open source tools but it is still a lot of stuff to get working together. I'm willing to meet them halfway and boot over to Windows 7 to get all that. What I would really like is for Actel to publish the register level API for the FlashPro download cables. Then Open Source people could do their magic and write a really good linux driver. Linux drivers are not that hard to do now with libusb allowing user space drivers. Anyway, I just like it when FPGA vendors put out good solid software. Linux support is really secondary for me. PeteArticle: 148462
On Jul 25, 2:15=A0am, Rob <noth...@nowhere.com> wrote: > Hi, > > Using Altera Model-Sim to do a gate level simulation. The .vo file that > is produced doesn't seem to be modeling the internal RAM's correctly. In > the design they are instantiated as 12bit but the EDA netlist has them > as 4 bits. > > Any help on this? Has anyone experienced a similar problem? > > Regards, > Rob Best to read the memory section of the device datasheet to see why it's splitting into 3 x 4 bit blocks. For example a M9k in stratix can be split into following during synthesis: 8K=D71 4K=D72 2K=D74 1K=D78 1K=D79 512=D716 512=D718 256=D732 256=D736 What your seeing is expected behaviour. Best Regards DGArticle: 148463
On Jul 26, 8:54=A0am, dgreig <dgr...@ieee.org> wrote: > On Jul 25, 2:15=A0am, Rob <noth...@nowhere.com> wrote: > > > Hi, > > > Using Altera Model-Sim to do a gate level simulation. The .vo file that > > is produced doesn't seem to be modeling the internal RAM's correctly. I= n > > the design they are instantiated as 12bit but the EDA netlist has them > > as 4 bits. > > > Any help on this? Has anyone experienced a similar problem? > > > Regards, > > Rob > > Best to read the memory section of the device datasheet to see why > it's splitting into 3 x 4 bit blocks. For example a M9k in stratix can > be split into following during synthesis: > 8K=D71 > 4K=D72 > 2K=D74 > 1K=D78 > 1K=D79 > 512=D716 > 512=D718 > 256=D732 > 256=D736 > What your seeing is expected behaviour. > > Best Regards > DG I should mention that a M9k, for example, can be split into 2 x 4.5k blocks.Article: 148464
Hi, I'm interfacing Actel FPGA with Freescale Coldfire Processor. This interface is operating @ 75Mhz. FPGA output signal (TA -Transfer acknowledge) and FPGA data out is sampled at rising edge by Processor. As per Coldfire Processor datasheet, setup time for this signals is 9ns and 0ns is hold time. I am giving constraints as follows. #Period constraint create_clock -name { i_PROC_CLKOUT } -period 13.333 -waveform { 0.000 6.667 } { i_PROC_CLKOUT } set_input_delay 11.667 -clock { i_PROC_CLKOUT } [get_ports { i_PROC_CS1n }] # adding 1ns to account PCB trace delay set_output_delay 10.000 -clock { i_PROC_CLKOUT } [get_ports { o_PROC_TAn }] Here if I just delay my input signal and connected to output pin, my timings are not met (slack is -4.745ns). How do operate the design (glue logic) at 75MHz without any timing violations? always @(posedge i_PROC_CLKOUT or negedge i_RESETn) begin if(i_RESETn == 1'b0) r_sync_proc_cs1n <= 1'b1; else r_sync_proc_cs1n <= i_PROC_CS1n ; end assign o_PROC_TAn = r_sync_proc_cs1n; Thanks in advance.Article: 148465
1.What is a stable clock? 2.How can i generate using DCM in xilinx? or vhdl? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148466
chinnathurai <chinnathurai.c@n_o_s_p_a_m.rediffmail.com> wrote: > 1.What is a stable clock? > 2.How can i generate using DCM in xilinx? or vhdl? What did you do to try to understand these problems? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 148467
Hi, As I understand it, good practice dictates that in a synthesis-targeted setting, components should use ports of type std_logic or std_logic_vector only. Certainly Xilinx's IP generation tools provide components with this philosophy. My design is well-suited to the use of signed types from IEEE.Numeric_Std. From my investigations I believe that the correct way to connect signed signals to std_logic_vector ports is by converting the types in the component instantiation port map. E.g., where x and y are compatibly- sized signed signals: U1: somedevice port map ( DIN => std_logic_vector(x), signed(DOUT) => y); Xilinx ISE (12.1) simulates this without problems. Xilinx XST complains, however, with "ERROR:Xst:1539 - <VHDL file name> line xx: Formal port in component U1 must be an identifier". The obvious work-around, suggested at http://www.xilinx.com/support/answers/18188.htm, is to add a signal: signal U1DOUT : std_logic_vector(7 downto 0); ... y < signed(U1DOUT); U1: somedevice port map ( DIN => std_logic_vector(x), DOUT => U1DOUT); This is pretty ugly and gets uglier with dynamic widths, "generate" statements and so on. Is the simpler approach above invalid VHDL or is XST just exhibiting yet more broken behaviour? Thanks in advance, 0xADFArticle: 148468
all, I would like some feedback on a new FPGA architecture. Are there any serious configurable logic gurus on this group? If there is interest, I will post links to the 3 published papers that discuss in detail a logic architecture that offers better than 10x higher logic density than standard FPGA, along with a significant reduction in power. The research presents an architecture that can leverage "temporal logic folding". thanks.Article: 148469
On Jul 26, 8:30=A0am, Andrew Feldhaus <Re...@thread.pls> wrote: > Hi, > > As I understand it, good practice dictates that in a synthesis-targeted > setting, components should use ports of type std_logic or std_logic_vecto= r > only. > > Certainly Xilinx's IP generation tools provide components with this > philosophy. > > My design is well-suited to the use of signed types from IEEE.Numeric_Std= . > > From my investigations I believe that the correct way to connect signed > signals to std_logic_vector ports is by converting the types in the > component instantiation port map. =A0E.g., where x and y are compatibly- > sized signed signals: > > U1: somedevice > =A0 port map ( =A0DIN =3D> std_logic_vector(x), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 signed(DOUT) =3D> =A0y); > > Xilinx ISE (12.1) simulates this without problems. > > Xilinx XST complains, however, with "ERROR:Xst:1539 - <VHDL file name> > line xx: Formal port in component U1 must be an identifier". =A0The obvio= us > work-around, suggested athttp://www.xilinx.com/support/answers/18188.htm, > is to add a signal: > > signal =A0U1DOUT : std_logic_vector(7 downto 0); > ... > y < signed(U1DOUT); > U1: somedevice > =A0 port map ( =A0DIN =3D> std_logic_vector(x), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 DOUT =3D> U1DOUT); > > This is pretty ugly and gets uglier with dynamic widths, "generate" > statements and so on. =A0Is the simpler approach above invalid VHDL or is > XST just exhibiting yet more broken behaviour? > > Thanks in advance, > > 0xADF I don't recall the syntax used for conversions in port maps. Have you tried port map ( DIN =3D> std_logic_vector(x), DOUT =3D> std_logic_vector(y)); I just use the clunkier method you outline above since this seems to be a sticky issue with various tools. Better to have the code work across tools than to worry about being "pretty". BTW, you use the term "correct" to describe the port map conversion. If it doesn't work, then I don't consider it to be "correct". Git 'er done! RickArticle: 148470
Hello, I would like to run several simulations one after another with code coverage on modelsim. This is because I have several testbenches, each one testing a particular aspect of the design. However I would like, at the end, to get a coverage report taking in account every simulations I have run. I believe this could be done but I can't find any solid documentation on code coverage command line options (even in model sim command line user guide). Does anyone have some clues on how to achieve this? Thanks in advance.Article: 148471
On Jul 26, 8:30=A0am, Andrew Feldhaus <Re...@thread.pls> wrote: > > This is pretty ugly and gets uglier with dynamic widths, "generate" > statements and so on. =A0Is the simpler approach above invalid VHDL or is > XST just exhibiting yet more broken behaviour? > The code is correct, brand X tools are deficient in this instance. One way to hide the ugliness a bit is to create a wrapper around the X generated IP that then has the interface that you want. Then do the work around in the architecture of the wrapper. If you're only using a small number of such IP blocks but instantiating them several places this may not be too bad. If you only instantiate the IP block once, and you're married to using X and their toolset then you'll have to live with the workaround. KJArticle: 148472
On Jul 26, 10:27=A0am, rickman <gnu...@gmail.com> wrote: > If it doesn't > work, then I don't consider it to be "correct". > If 'it' is the brand X tools, then I agree. If 'it' is standard compliant code that is not being processed properly by brand X tools, then I disagree. Correctness is determined by compliance to the standard, not to some lowest common denominator implementation of that standard. The need to get the job done though is determined by working around whatever shortcomings come along with the tools and parts that have been chosen. KJArticle: 148473
Hi all, In my Cyclone 4 based design I'm getting an embedded multiplier inferred, as expected from the following VHDL: C <= A * B; (where A and B are registered 12 bit values, and the output C is subsequently registered, with no other logic in the path) However I'm seeing a timing violation on this path. Looking at the timing reports, there is nearly a 2ns delay between the output of the multiplier and the flop. Obviously I'd really like to pull in some of this 2ns, which would sort out the negative slack problem. I looked through the documentation for the embedded multipliers, and as expected there are input and output registers as part of the embedded multiplier block. But clearly with that 2ns delay the output register isn't being used. So my question is: how do I write my code to infer the use of the output registers in the embedded multipliers? As I tried a number of coding styles, including putting the multiplication operation directly inside a clocked process and it had no impact on timing. But I definitely don't want to instantiate the embedded multiplier directly. Perhaps there are any VHDL attributes that may help (anything other than MULTSTYLE DSP/LOGIC)? Any suggestions or pointers to documents would be greatly appreciated!Article: 148474
On Jul 26, 4:53=A0am, "chinnathurai" <chinnathurai.c@n_o_s_p_a_m.rediffmail.com> wrote: > 1.What is a stable clock? It's what horses use to tell time. -a
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z