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
What do you mean with "GPP" ? Peter Alfke, who hates unexplained TLAs (Three-Letter-Acronyms). On Mar 18, 9:44 pm, yasi...@gmail.com wrote: > Hi, > > I couldn't find any comparison between FPGA and GPP. I thought I could > get some of the expert two-cents on this matter especially in terms of > cost, power and performance from this group. > > Cheers, > AceArticle: 116801
Hello, This source is a capture the ADC0804 with FPGA Spartan3,
Oscillator 50MHz
frequency Clk for ADC is 650KHz, sampling frequency 8Hz, show the
data capture in array leds.
//##############adc08.v###################
//#########Develp by Jhoberg Quevedo############
//#########email: jrquevedor@gmail.com###########
module adc08(clkadc,adc,adccs,adcwr,adcintr,led,osc);
parameter Nosc=32;
input osc;
input adcintr;
input [7:0] adc;
output clkadc;
output adccs;
output adcwr;
output [7:0] led;
reg clkadc;
reg adccs;
reg adcwr;
reg [7:0] dato;
reg [7:0] led;
reg [Nosc:0] tcont;
reg [7:0] tclk;
always @(posedge osc)
begin
tcont=tcont+1;
tclk=tclk+1;
if(tcont==6250000)
begin
tcont=0;
if (adccs)
begin
adccs=0;
adcwr=0;
end
else
begin
adccs=1;
adcwr=1;
end
end
if (tclk==77)
begin
tclk=0;
if (clkadc)
clkadc=0;
else
clkadc=1;
end
end
always @(posedge adcintr)
begin
led=adc;
end
endmodule
#####################adc08.v#####################
Article: 116802On 2007-03-19, Peter Alfke <alfke@sbcglobal.net> wrote: > What do you mean with "GPP" ? > Peter Alfke, who hates unexplained TLAs (Three-Letter-Acronyms). He probably means "general purpose processors". I'm sure with that detail you can now provide crystal clear guidance on "FPGA vs. GPP". :-) -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/ From invalid@dont.spam Sun Mar 18 21:31:27 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny05.POSTED!933f7776!not-for-mail From: Phil Hays <invalid@dont.spam> Subject: Re: FPGA vs. GPP anyone? User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.03.19.05.31.28.44666@dont.spam> Newsgroups: comp.arch.fpga References: <1174279480.590644.221340@l75g2000hse.googlegroups.com> <1174280922.838277.91090@p15g2000hsd.googlegroups.com> <slrnevs7h9.m4e.ben@saturn.home.ben.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 14 Date: Mon, 19 Mar 2007 05:31:27 GMT NNTP-Posting-Host: 71.112.133.239 X-Complaints-To: abuse@verizon.net X-Trace: trndny05 1174282287 71.112.133.239 (Mon, 19 Mar 2007 01:31:27 EDT) NNTP-Posting-Date: Mon, 19 Mar 2007 01:31:27 EDT Xref: prodigy.net comp.arch.fpga:128387 X-Received-Date: Mon, 19 Mar 2007 01:31:28 EDT (newsdbm02.news.prodigy.net) Ben Jackson wrote: > On 2007-03-19, Peter Alfke <alfke@sbcglobal.net> wrote: >> What do you mean with "GPP" ? > He probably means "general purpose processors". I'm sure with that detail > you can now provide crystal clear guidance on "FPGA vs. GPP". For what problem? -- Phil HaysArticle: 116803
sorry 'bout that. Yup, I was directing to the "general purpose procesor"Article: 116804
On 2007-03-12, Ray Andraka <ray@andraka.com> wrote: > My guess is you have an RPM that straddles a DSP or BRAM column. There > is a bug in the mapper that has been there since 6.3 that messes up the > grid mapping when an RPM has elements on both sides of a non-LUT column. > The result is if you have a RAM16, SRL16 or other element that > requires a LUT memory resource and it is placed on the opposite side of > a BRAM or DSP column relative to the RLOC origin, it will fail to place. > I think it may have gotten even more broken in 8.2 so that purely LUT > RPMs also can't straddle a non-LUT resource. I don't think this is the case because my design is placed correctly if I synthesize the design with XST 8.1 and place and route it using 8.2 or 9.1. (I did run into the problem you described a couple of months ago and a posting by you helped me solve that one.) I got some help from Xilinx on this issue and I might have to work around the problem by using constraints in the UCF file instead. It might also be that I am doing something weird in my code :) All in all, I think that RLOCs might be more work than they are worth in my case but it has been interesting to learn a bit more about them and get some feeling for when they might be useful. One experince I have had is that once you start to RLOC a module you really need to RLOC the modules that are closely connected to it as well, otherwise you will probably get suboptimal timing as compared to just letting par place everything automatically. /AndreasArticle: 116805
> > It depends on how much bandwidth you need and whether or not you can spare the logic for > the necessary memory controller. > > I am working on a high-performance memory controller of my own to interface a PC3200 DDR > DIMM to an XC2VP30 that can sustain anywhere from 100% read to 100% write and my > preliminary data says this is pretty expensive: my final memory controller will consume > about 40 BRAMs out of 136. About half of the BRAM cost comes from the quad x36 internal > memory ring bus controllers' FIFOs and most of the other half comes from the dual-ported > back-end's 128bits wide FIFOs. This design is overkill for a VP30 but I am currently > unemployed so I am simply killing time by doing something that may be useful later - or at > the very least instructive since I have never interfaced DRAMs directly before. > > If your DRAMs provide you only a 32bits-wide data bus and you can operate your internal > data path at twice the DDR clock, things get much simpler and smaller. A 0 BRAM memory > controller would be possible under these conditions... but I'd still slap on a BRAM FIFO > or three (local RX, local TX, pass-through) with extra logic to 'ringify' it if more than > one or two function blocks are going to share access. Thanks a lot Daniel. Actually, I am still quite new to fpga but I have been just tasked with this very difficult project (of video scaling), at least to me. Somehow I am to solve the problems of the block rams. (In addition, I didn't mention that I would also have to convert the DSP48s used in the Virtex to using the CLB in the Spartan). Well, anyway, been much help, at least I understand there is a probable chance of using the DDR SDRAM as block rams replacements. (Though I suspect there is also speed problems for doing so) Oh great attitude there, imo, on keeping on doing useful things!Article: 116806
"skyworld" <chenyong20000@gmail.com> writes: > Hi, > i have used a parallel cable to download bitfile into my Virtex 4 > FPGA. But when open Chipscope with this cable, the computer said it > can't found the cable. Do anybody know how to solve this? thanks. > Do you still have Impact open? It will "keep" the cable so that Chipscope can't access it. You have to close Impact and then open chipscope. Or just open Chipscope in the first place as it can send bitfiles to the FPGA as well. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 116807
Hi Bob, Yes, I've actually done this and it works. I didn't use or port the XSVF Player, because when I didn't know about it until I had half of my code finished already. I based my code on the XSVF file description in XAPP503. I found it is sufficient to program an XCF08P chip, but not for a V4FX FPGA. The FPGA XSVF file uses some states not covered in XAPP503. They are covered in the source code of XAPP058 and actually they are not difficult to guess either. For what it's worth: The XSVF is about the same size as the (ASCII) MCS file. It's binary but contains lots of redundant patterns. Unfortunately the XCF08P erase time is very slow, because it's implemented as simple delay. The XCF08P datasheet documents how to poll the erase state, so it's possible to "replace" the delay with a poll function on-the-fly in your XSVF interpreter code. In theory you can't stream an XSVF file because the byte order of some commands require you to access the last byte first. The command size can be any 32-bit integer, so effectively this puts an unknown memory size requirement on your embedded stream buffer. It can be as large as the whole file size. In practice however, I never observed commands larger than 768 bytes produced by Impact as XSVF generator. To be on the safe side, my code interprets the XSVF on the Windows PC, and produces a stream of proprietary command tokens. This stream is sent to an 8-bit MCU on my target board to produce the actual JTAG patterns. To produce the XSVF file with Impact (batch mode), I found the most simple solution is to load a working project file with all chips already configured. This reduces the size of the batch command file to less than 10 lines. I hope this helps, MarcArticle: 116808
Hi All, I have sent to alt.sources very "quick & dirty" extensions to Altera's Jam STAPL Player, allowing it to work with multiple JTAG chains interfaced with SCANSTA111 bridge, and making programming faster, when using a fast, but high latency interface (like some kinds of VME or USB). The main idea is to cache JTAG writes, and use block transfer to speed up programming (however the interface itself or th receiving side must take care of the appropriate timing). The code is placed as public domain. No warranty at all. If anybody finds it useful, or at least inspiring, I'll be glad. -- Regards, Wojtek PS. This is the google link to my post: http://groups.google.pl/group/alt.sources/browse_frm/thread/14749b0c309c468b/16c9cb91e4ec23bbArticle: 116809
On 19 Mrz., 06:40, "Ace" <yasi...@gmail.com> wrote: > sorry 'bout that. Yup, I was directing to the "general purpose > procesor" The answer is, it depends. You can find a detailed view of the tradeoffs here: http://ic.ese.upenn.edu/transit/rcgp/rcgp.html The basic point is, that each architecture is most efficient on a problem that matches it's instruction and data granularity. For a problem with 32-bit data that maps well to the instructions available in a given ISA and that does not have a lot more inherent parallelism than what the available ISA implementation offers a general purpose CPU is very good. An ASIC implementation can exactly match the data types, instructions and spation parallelism that suits a problem, so it has a big advantage there, but it is inefficient in the sense that it must make a lot of worst case assumptions. (e.g. it implements always the same number of processing elements no matter what size the problem instance is. The FPGA inherits essentially all advantages of the ASIC implementation at a price of a factor of 10x to 20x worse area/delay product. For certain applications the FPGA can more than compensate for that by its ability to tailor the hardware to the problem instance. Kolja SulimmaArticle: 116810
Hi there! I am wondering what the default IOSTANDARD is on pins for which it is not explicitly assigned in the UCF of the project. Here, the project uses LVCMOS25 for some pins where nothing is set explicitly - is that always the default value? Is it a good style to always define the IOSTANDARD in any case? Thanks for any hints, TorstenArticle: 116811
Torsten Landschoff wrote: > Hi there! > > I am wondering what the default IOSTANDARD is on pins for which it is > not explicitly assigned in the UCF of the project. Here, the project > uses LVCMOS25 for some pins where nothing is set explicitly - is that > always the default value? Is it a good style to always define the > IOSTANDARD in any case? Yes, the default is LVCMOS25. I always specify the IOSTANDARD, but I usually don't use LVCMOS25. --- Joe Samson Pixel VelocityArticle: 116812
Hello John,
> I hope we will also be finally showing the DDR2 and SDRAM modules for
> Raggedstone1 this week or maybe next. They have been assembled and
> awaiting test for those interested in these. Proving there are not any
> issues they they will be on sale shortly after.
Michael Gernoth and I am very interested in this. Can you give us a
heads up when the modules are available?
Thomas
Article: 116813On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote: > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote: > > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @* > > block. > > Here's a (perhaps poor) example: > > > reg signed [15:0] table [0:255]; > > reg signed [23:0] sum; > > > integer i; > > always @* > > begin > > sum = 0; > > for ( i =0; i < 256; i = i + 1 ) > > sum = sum + table[i]; // yes, I know this will synthesize a suboptimal > > imbalanced adder-tree! > > end > > Correct me if I'm wrong, but I believe that this is not valid verilog > - you cannot use an array as a term in the always() sensitivity list, > and the always* implies that the array is in the sensitivity list. I > know that the ncverilog simulator warns about this (but does work). It > states that this is non-portable verilog. Synopsys DC does indeed > synthesize this correctly, but it's not a good idea to use non- > standard verilog statements. ISE seems to err on the side of adhering > to the strict rules of the verilog language. I could be wrong about > this, but from the warning given by ncverilog, I believe this to be > the case. Maybe try a verilog linting tool? formality/conformal should > set you straight, if you have them. > Cheers > John I think the wrong isn't due to the sensitivity list. Do you sure the error in ISE is caused by that?Article: 116814
Ken Soon wrote: >> It depends on how much bandwidth you need and whether or not you can spare > the logic for >> the necessary memory controller. >> >> I am working on a high-performance memory controller of my own to > interface a PC3200 DDR >> DIMM to an XC2VP30 that can sustain anywhere from 100% read to 100% write > and my >> preliminary data says this is pretty expensive: my final memory controller > will consume >> about 40 BRAMs out of 136. About half of the BRAM cost comes from the quad > x36 internal >> memory ring bus controllers' FIFOs and most of the other half comes from > the dual-ported >> back-end's 128bits wide FIFOs. This design is overkill for a VP30 but I am > currently >> unemployed so I am simply killing time by doing something that may be > useful later - or at >> the very least instructive since I have never interfaced DRAMs directly > before. >> If your DRAMs provide you only a 32bits-wide data bus and you can operate > your internal >> data path at twice the DDR clock, things get much simpler and smaller. A 0 > BRAM memory >> controller would be possible under these conditions... but I'd still slap > on a BRAM FIFO >> or three (local RX, local TX, pass-through) with extra logic to 'ringify' > it if more than >> one or two function blocks are going to share access. > > Thanks a lot Daniel. Actually, I am still quite new to fpga but I have been > just tasked with this very difficult project (of video scaling), at least to > me. Somehow I am to solve the problems of the block rams. (In addition, I > didn't mention that I would also have to convert the DSP48s used in the > Virtex to using the CLB in the Spartan). > > Well, anyway, been much help, at least I understand there is a probable > chance of using the DDR SDRAM as block rams replacements. (Though I suspect > there is also speed problems for doing so) > > Oh great attitude there, imo, on keeping on doing useful things! Spartan 3 has hardware multipliers, so you are not entirely stuck with doing everything in CLBs... only the accumulate, multiplexing and few other unique features you might not have used. If you inferred those DSPs, you should not need to do anything in particular for the Spartan switch. For the DRAMs, first estimate the peak bandwidth you need and the best-case the memory you have can do. If your requirement is less than 75% of your memory's theoretical maximum, it should be doable with a relatively simple memory controller but you will most likely have to re-think your pipeline to accomodate the extra latency: you will at least have to add logic to prefetch data and BRAMs to buffer both the input(s) and output(s). You can start with pipelined bursts of eight words to do full-row transfers to start - video applications can usually be made very compatible with full-row transfers. For more random memory access patterns, bank interleaving and hiding precharge/activate behind burst transfers to other banks is practically mandatory to achieve better than 50%. Experience with DRAMs is often listed as an asset on jobs I am looking at so I am trying to complete a relevant design in case I get an interview for one of these. Things are progressing slowly and I am expecting lots of grief from the IOB side, in part due to inexperience and in part because the V2Pro's IOBs appear to be more quirky than the V4s I have worked on last year.Article: 116815
On Mar 19, 5:45 am, Wojciech Zabolotny <w...@ise.pw.edu.pl> wrote: > I have sent to alt.sources very "quick & dirty" extensions to Altera's > Jam STAPL Player, allowing it to work with multiple JTAG chains > interfaced with SCANSTA111 bridge, and making programming faster, when > using a fast, but high latency interface (like some kinds of VME > or USB). > The main idea is to cache JTAG writes, and use block transfer to > speed up programming (however the interface itself or th receiving side > must take care of the appropriate timing). > The code is placed as public domain. No warranty at all. If anybody > finds it useful, or at least inspiring, I'll be glad. Very interesting - I may have to take a look at that as I've crudely done something very similar, intended only for rare usage but am now using it enough that it would be worth getting right. Major question though: how are you building it? What compiler, and have you come up with a sane Makefile? GCC (win32) produced irreconcilable errors. Haven't been able to make it into a sensible visual C project, though visual C will process the makefile - so I can compile it, but as a sort of ugly end-run around the IDE's concept of a project.Article: 116816
On 19 Mar, 14:30, cs_post...@hotmail.com wrote: > Major question though: how are you building it? What compiler, and > have you come up with a sane Makefile? GCC (win32) produced > irreconcilable errors. Haven't been able to make it into a sensible > visual C project, though visual C will process the makefile - so I can > compile it, but as a sort of ugly end-run around the IDE's concept of > a project. I use Linux, so I don't know about any Windows-specific questions... The file being the final part of the message is the "shar" archive, so you need to use something like "$unshare < saved_message.txt" to recover the files my_jtag.h and my_jtag.c . To compile the files themselves you may use just: $gcc -c my_jtag.c However to make full use of this sources you also need to download Jam STAPL Player sources, modify the names of the replaced functions, implement your low level I/O routines, modify the makefile to include the my_jtag.o and so on... So this is rather a draft of the solution, not the complete solution. The full solution has been tested with VME and CAEN controller, but I'm afraid I can not publish it. I'm going to write the USB based JTAG programmer with simple microcontroller and the modified Jam Player on the PC side, but I have no time to finish the design :- ( (it will be GPL'ed). -- Regards, WojtekArticle: 116817
I am seeking information on QuickSilver Technology's "Adaptive Computing System" framework. Their infrastructure sounded like it would be a really good fit for some work we are doing at NASA MSFC. It appears QuickSilver closed up shop in early 2005... Is anyone here familiar with their architecture framework, and if so, is it still available in any form? Were they any platforms that actually successfully used their offerings? I'd appreciate any information anyone could provide. Thanks, Anne anne.l.atkinson@nasa.govArticle: 116818
On Mar 19, 8:53 am, "wzab" <wza...@gmail.com> wrote: > On 19 Mar, 14:30, cs_post...@hotmail.com wrote: > > > Major question though: how are you building it? What compiler, and > > have you come up with a sane Makefile? GCC (win32) produced > > irreconcilable errors. > To compile the files themselves you may use just: > $gcc -c my_jtag.c > However to make full use of this sources you also need to download Jam > STAPL Player > sources, modify the names of the replaced functions, implement your > low level I/O routines, > modify the makefile to include the my_jtag.o and so on... So you were able to get some unix make utility and GCC to process the included makefile for the jam player? I couldn't get the combination of GNU make (cygwin win32) and GCC (cygwin win32) to do so (a bunch of wierd errors about circular definitions) which is what prompted my question.Article: 116819
On 16 mar, 16:53, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 16 Mar 2007 08:14:18 -0700, "John_H"
>
> <newsgr...@johnhandwork.com> wrote:
> >"VHDL_HELP" <abai...@gmail.com> wrote in message
> >news:1174054292.325732.224840@y80g2000hsf.googlegroups.com...
> ><snip>
> >> -----------------------------
> >> this is my problem:
> >> for the s(0) , s(1) , s(2) and s(3) it gives me the numbers but for s
> >> in simulation i have as a result 4'hU and 4'hX
>
> >is there *anything* that might go wrong with the addition given
> >the libraries he has specified?
>
> Don't think so (although my dislike of STD_LOGIC_UNSIGNED
> is well enough known by now).
>
> The problem is simpler: SEQ_LOOP is an infinite loop
> containing an implicit state machine. The loop exits
> only when reset is asserted. If reset is held false, the
> loop continues to iterate and the final assignment
> is never executed, so 's' is never updated.
>
> Could we please find the tutor (or book writer, or other
> "authority") who is teaching beginners to use this
> form of implicit state machine, and string him/her
> up by a rope tied around some sensitive appendage?
>
> It makes my blood boil so much that I'm willing to post
> the (obvious, simple) code that works - assuming
> the use of NUMERIC_STD instead of STD_LOGIC_ARITH:
>
> process (clk, reset)
> subtype T_chiffre is unsigned(3 downto 0);
> type T_tableau4x4 is array (0 to 3) of T_chiffre;
> variable lieu: unsigned(1 downto 0);
> variable t: T_tableau4x4;
> variable somme: T_chiffre;
> begin
> if reset =3D '1' then
> -- remettre tout =E0 zero
> lieu :=3D "00";
> t :=3D (others =3D> (others =3D> '0'));
> clk_out <=3D '0';
> s <=3D (others =3D> '0');
> elsif rising_edge(clk) then
> -- faire le somme en ajoutant chaque numero memoris=E9
> somme :=3D (others =3D> '0');
> for i in t'range loop
> somme :=3D somme + t(i);
> end loop;
> -- mettre le somme en m=E9moire "s"
> s <=3D somme;
> -- sauvegarder le num=E9ro prochain
> t(to_unsigned(lieu)) :=3D en;
> -- ??? horloge /2 ???
> clk_out <=3D not lieu(0);
> -- pr=E9parer pour boucle prochain
> lieu :=3D lieu + 1;
> end if;
> end process;
>
> Beware of arithmetic overflow. Output gives the sum of the
> most recently seen 4 values. I have no idea why you want
> clk_out.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
hi every body ,
i want to say thank you for all of u and this program can do the sum
that i want
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity som is
Port ( clk : in STD_LOGIC;
reset : in STD_LOGIC;
en : in STD_LOGIC_VECTOR (2 downto 0);
clk_out : out STD_LOGIC;
so : out STD_LOGIC_VECTOR (3 downto 0);
sor : out STD_LOGIC_VECTOR (3 downto 0));
end som;
architecture Behavioral of som is
TYPE TAB IS ARRAY(3 DOWNTO 0) OF STD_LOGIC_VECTOR(2 DOWNTO 0);
signal t:TAB;
SIGNAL s:STD_LOGIC_VECTOR (3 downto 0):=3D"0000";
begin
process
begin
seq:loop
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '1';
t(0) <=3D en;
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '0';
t(1) <=3D en;
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '1';
t(2) <=3D en;
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '0';
t(3) <=3D en;
----- Mettre les =E9l=E9ments de tableau en sortie
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '1';
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '0';
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '1';
wait until clk'event and clk =3D '1';
exit seq when reset =3D'1';
clk_out <=3D '0';
end loop;
if reset =3D '1' then
clk_out <=3D '0';
s <=3D '0' & t(0) + t(1) + t(2) + t(3);
so <=3D s;
end if;
end process;
end Behavioral;
--- thank you again
Article: 116820On Mar 19, 6:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote: > On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote: > > > > > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote: > > > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @* > > > block. > > > Here's a (perhaps poor) example: > > > > reg signed [15:0] table [0:255]; > > > reg signed [23:0] sum; > > > > integer i; > > > always @* > > > begin > > > sum = 0; > > > for ( i =0; i < 256; i = i + 1 ) > > > sum = sum + table[i]; // yes, I know this will synthesize a suboptimal > > > imbalanced adder-tree! > > > end > > > Correct me if I'm wrong, but I believe that this is not valid verilog > > - you cannot use an array as a term in the always() sensitivity list, > > and the always* implies that the array is in the sensitivity list. I > > know that the ncverilogsimulatorwarns about this (but does work). It > > states that this is non-portable verilog. Synopsys DC does indeed > > synthesize this correctly, but it's not a good idea to use non- > > standard verilog statements.ISEseems to err on the side of adhering > > to the strict rules of the verilog language. I could be wrong about > > this, but from the warning given by ncverilog, I believe this to be > > the case. Maybe try a verilog linting tool? formality/conformal should > > set you straight, if you have them. > > Cheers > > John > > I think the wrong isn't due to the sensitivity list. Do you sure the > error inISEis caused by that? Hi, This is something that was supposed to be supported in ISE XST in 9.1i, although the change did not make it in time. Thanks DuthArticle: 116821
On Mar 19, 5:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote:
> On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote:
>
>
>
> > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
>
> > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > > block.
> > > Here's a (perhaps poor) example:
>
> > > reg signed [15:0] table [0:255];
> > > reg signed [23:0] sum;
>
> > > integer i;
> > > always @*
> > > begin
> > > sum = 0;
> > > for ( i =0; i < 256; i = i + 1 )
> > > sum = sum + table[i]; // yes, I know this will synthesize a suboptimal
> > > imbalanced adder-tree!
> > > end
>
> > Correct me if I'm wrong, but I believe that this is not valid verilog
> > - you cannot use an array as a term in the always() sensitivity list,
> > and the always* implies that the array is in the sensitivity list. I
> > know that the ncverilog simulator warns about this (but does work). It
> > states that this is non-portable verilog. Synopsys DC does indeed
> > synthesize this correctly, but it's not a good idea to use non-
> > standard verilog statements. ISE seems to err on the side of adhering
> > to the strict rules of the verilog language. I could be wrong about
> > this, but from the warning given by ncverilog, I believe this to be
> > the case. Maybe try a verilog linting tool? formality/conformal should
> > set you straight, if you have them.
> > Cheers
> > John
>
> I think the wrong isn't due to the sensitivity list. Do you sure the
> error in ISE is caused by that?
I ran the following testcase through ncverilog:
module test;
reg [7:0] array [0:7];
reg [2:0] idx;
reg [7:0] out;
always@*
begin
out = array[idx];
end
endmodule
The logfile gives the following warnings:
always@*
|
ncvlog: *W,STARMR (array.v,8|6): @* containing memory reference not
standard or portable.
out = array[idx];
ncvlog: *W,MRSTAR (array.v,10|11): memory reference that was not
standard in @*.
module worklib.test:v
So clearly always @* when used with an array is non part of the
verilog standard.
Cheers
John
Article: 116822On Mar 19, 7:31 am, "John McGrath" <tail...@gmail.com> wrote: > On Mar 19, 5:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote: > > > > > On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote: > > > > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote: > > > > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @* > > > > block. > > > > Here's a (perhaps poor) example: > > > > > reg signed [15:0] table [0:255]; > > > > reg signed [23:0] sum; > > > > > integer i; > > > > always @* > > > > begin > > > > sum = 0; > > > > for ( i =0; i < 256; i = i + 1 ) > > > > sum = sum + table[i]; // yes, I know this will synthesize a suboptimal > > > > imbalanced adder-tree! > > > > end > > > > Correct me if I'm wrong, but I believe that this is not valid verilog > > > - you cannot use an array as a term in the always() sensitivity list, > > > and the always* implies that the array is in the sensitivity list. I > > > know that the ncverilog simulator warns about this (but does work). It > > > states that this is non-portable verilog. Synopsys DC does indeed > > > synthesize this correctly, but it's not a good idea to use non- > > > standard verilog statements. ISE seems to err on the side of adhering > > > to the strict rules of the verilog language. I could be wrong about > > > this, but from the warning given by ncverilog, I believe this to be > > > the case. Maybe try a verilog linting tool? formality/conformal should > > > set you straight, if you have them. > > > Cheers > > > John > > > I think the wrong isn't due to the sensitivity list. Do you sure the > > error in ISE is caused by that? > > I ran the following testcase through ncverilog: > > module test; > > reg [7:0] array [0:7]; > reg [2:0] idx; > reg [7:0] out; > > always@* > begin > out = array[idx]; > end > > endmodule > > The logfile gives the following warnings: > > always@* > | > ncvlog: *W,STARMR (array.v,8|6): @* containing memory reference not > standard or portable. > out = array[idx]; > ncvlog: *W,MRSTAR (array.v,10|11): memory reference that was not > standard in @*. > module worklib.test:v > > So clearly always @* when used with an array is non part of the > verilog standard. > > Cheers > John You could alternately use: always @(idx) in place of always@*Article: 116823
On Mar 19, 7:35 am, "bluesclues" <deepak.l...@gmail.com> wrote: > On Mar 19, 7:31 am, "John McGrath" <tail...@gmail.com> wrote: > > > > > On Mar 19, 5:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote: > > > > On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote: > > > > > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote: > > > > > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @* > > > > > block. > > > > > Here's a (perhaps poor) example: > > > > > > reg signed [15:0] table [0:255]; > > > > > reg signed [23:0] sum; > > > > > > integer i; > > > > > always @* > > > > > begin > > > > > sum = 0; > > > > > for ( i =0; i < 256; i = i + 1 ) > > > > > sum = sum + table[i]; // yes, I know this will synthesize a suboptimal > > > > > imbalanced adder-tree! > > > > > end > > > > > Correct me if I'm wrong, but I believe that this is not valid verilog > > > > - you cannot use an array as a term in the always() sensitivity list, > > > > and the always* implies that the array is in the sensitivity list. I > > > > know that the ncverilog simulator warns about this (but does work). It > > > > states that this is non-portable verilog. Synopsys DC does indeed > > > > synthesize this correctly, but it's not a good idea to use non- > > > > standard verilog statements. ISE seems to err on the side of adhering > > > > to the strict rules of the verilog language. I could be wrong about > > > > this, but from the warning given by ncverilog, I believe this to be > > > > the case. Maybe try a verilog linting tool? formality/conformal should > > > > set you straight, if you have them. > > > > Cheers > > > > John > > > > I think the wrong isn't due to the sensitivity list. Do you sure the > > > error in ISE is caused by that? > > > I ran the following testcase through ncverilog: > > > module test; > > > reg [7:0] array [0:7]; > > reg [2:0] idx; > > reg [7:0] out; > > > always@* > > begin > > out = array[idx]; > > end > > > endmodule > > > The logfile gives the following warnings: > > > always@* > > | > > ncvlog: *W,STARMR (array.v,8|6): @* containing memory reference not > > standard or portable. > > out = array[idx]; > > ncvlog: *W,MRSTAR (array.v,10|11): memory reference that was not > > standard in @*. > > module worklib.test:v > > > So clearly always @* when used with an array is non part of the > > verilog standard. > > > Cheers > > John > > You could alternately use: > > always @(idx) in place of always@* Maybe, but it would not work if the contents of the array were updated by a different process, independent of idx. I'm not sure how this would be syntesized - It may infer latches on the output, or error out. I'd be interested to see what happens Personally, for this example (asynch read of array elements) I'd use a continuous assignment. But personally I think verilog language should support @* in an array context, it works in all other contexts, and prevents unintentional latch inferral. As we can see from Duth, this will be added to ISE soon, and some other tools support it too, but they just warn that it is not strictly part of the standard. Cheers JohnArticle: 116824
I have a usb phy chip sitting on my opb_emc. I always have to use XIo_Out and XIo_In to access. Direct read/write to these addresses doesn't work. My problem is the access time is 100x slower than it should be. Howdo I get down to the access time the chip demands (50 ns)? Thanks, Clark
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