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
>Please suggest to your web developers that they...put technical >documentation...at permanent URLs... >Someone...pointed out years ago that URLs for real documents... >should be persistent. There was a paper on it, but I can't >find it now. Unfortunately few web developers have taken >this to heart. The point has probably been made in various places, but one is: http://www.useit.com/alertbox/980614.html MikeArticle: 127476
On Dec 27, 3:20=A0pm, MikeShepherd...@btinternet.com wrote: > >Please suggest to your web developers that they...put technical > >documentation...at permanent URLs... > >Someone...pointed out years ago that URLs for real documents... > >should be persistent. =A0There was a paper on it, but I can't > >find it now. =A0Unfortunately few web developers have taken > >this to heart. > > The point has probably been made in various places, but one is: > > =A0 =A0http://www.useit.com/alertbox/980614.html > > Mike I understand, and I agree somewhat. But we also have to realize that this is a fast-changing technology, and something that was cool and interesting in 2002 is now often obsolete and perhaps even misleading. That's why we want to overhaul the old TechXclusives, throw some away, and bring the others up to snuff. We want to cater to working engineers, not to archaeologists... An overview of FPGAs that stops with Virtex-II is not meaningful anymore, and neither are complex asynchronous FIFO explanations, when you get ready-made designs in the more modern Virtex chips. Sometimes we will annotate the old stories with warnings that there are better ways of designing with the more modern parts. The same considerations should be applied to application notes. Most of them that are 5 years old are more amusing than enlightening. Scary... Peter AlfkeArticle: 127477
Peter Alfke wrote: > The same considerations should be applied to application notes. Most > of them that are 5 years old are more amusing than enlightening. I've found very useful info that is still relevant but much more than five years old. For example, your asynchronous clock switching circuit, and Rob Weinstein's "flancter". This is exactly the sort of stuff that tends to get lost when someone gets a wild hair to "clean up the web site". Avnet dropped the flancter app note from their site even though Rob tried to push them to keep it. I've just used several flancters in a new design this week, but I had to beg on the newsgroup a few weeks ago to get people to send me a copy of the actual ap note. (Thanks to everyone that helped out!) So what if 98% of old XL4000 ap notes aren't relevant? It costs almost nothing to keep them archived in a directory somewhere, and the other 2% may contain useful design techniques that haven't been rewritten for the Virtex 5. These old app notes may help engineers create new designs for paying customers. Since some XL4000 series parts are still in production, there may even be engineers that occasionally have to maintain the designs or migrate them to newer families. Suppose the HDL source for something has an explanation like "see the example on page 12 of XAPP271828", but the app note and associated files are gone. I've been through that several time with other semiconductor vendors. I've always lamented how difficult it is to find data on old parts. When data sheets started being supplied in PDF form in the late 1980s, one of my friends said that the problem was solved and that the data would be around forever. I immediately disputed that point, and predicted that electronic data would be even more emphemeral than paper. Twenty years of experience confirm that. Sigh.Article: 127478
> xst has a quite good log output during synthesis. It precisely describes what it > synthesises at which line, and what gets eliminated for what reason. That may > give a clue about the reasons. At least for me, xst was always right and I caused > the problem... i'm afraid i have synthesized the multi-port register file alone as well as in a smaller context, and things there go well. i'm pretty sure that problems arise due to it being deep in the hierarchy. Kind regards Nikolaos KavvadiasArticle: 127479
> yes, i agree ... i had the same feeling and behavior on some of my > inference designs ... usually i could fix it by rewriting some pieces > of the code (and thus not fulfilling the template) to get it to > synthesize the logic i wanted ... although i must say it has improved > a lot, nowadays i only get it when i try to do something with > RAMB's... > > kind regards, > > Tim Hi, what i didn't say is that the block RAMs are always matched properly at high-level synthesis time. It is when going down to low-level synthesis that ISE chooses to delete some of them. Anyway, i now use instantiations as well in my multi-port register file generator. Now, the number of block RAMs is OK (none is deleted in low-level synthesis), still strangely some logic that is otherwise accessible is still being deleted. So, now it is probably the time that we are stepping onto my problematic code ;). Probably that weren't visible yet although the processor would run properly about 10 firmware applications in both simulator and S3SK environment (S3SK without the big register file). Still, i believe ISE has problems with elaborating code to an IR. I had to rewrite (either by hand or automatically) 4 times my code in order to see the correct number of BRAMs after low-level synthesis. All 4 cases work in simulation (GHDL). Kind regards Nikolaos KavvadiasArticle: 127480
> > The behavior of the design (did two versions: one with the VHDL code > > generated by an ANSI C 300-line program and one using generates using > > certain preprocessing for enabling the proper output multiplexers) is > > inferred properly by both XST 7.1 (patch 4) and 9.2 (unpatched) when i > > try to synthesize it as a top-level module. So this works. > > Is your objective a hardware description > for synthesis or or a netlist generator? The generator produces either generic RT-level VHDL code (BRAMs are inferrable) or VHDL code with block RAM instantations. I have a hand- written version with generates, too. > Maybe some of the dimensions line up cleanly > with the block ram structures while others don't. I'm sure that they actually do. > Consider writing a clean hdl description using block ram > templates and muxes and compare results with the present design. > Some related examples: http://home.comcast.net/~mike_treseler/sync_fifo.vhdhttp://home.comcast.net/~mike_treseler/stack.vhd Nice examples, but i have written a really clean description. > Consider a code template rather than a black box. > This gives synthesis some flexibility. This was my hope. I didn't want to mess with black-boxes , especially for something that is deep in the hierarchy. From a mental point of view (expanding and contracting the design port requirements not at the top-level) has problems. It could be doable, only if i was fixing all the affected entity declarations (the generic initial values for the number of read and write ports) throughout the design. I actually did this with Perl scripts, so there is no excuse for XST. > The main advantage to clean synthesis code is that the > synthesis and simulation models are the same thing. I also believe this in principle. > > I have posted some of the questions to the Xilinx forums, but no > > answers yet. Are the answering people all situated in the States (and > > are kind of sleeping at this moment)? > > No. Having a hot toddy at the holiday party ;) > > -- Mike Treseler AAhhh, we don't have holiday parties here. We used to staff ourselves with tons of pork, beef, liver and brains on a January day :) Kind regards Nikolaos KavvadiasArticle: 127481
How does one initialize 'nibbles' in verilog the same way as 'longreg' is initialised .. ? reg [1023:0] longreg = 576'h555555555555555D00014AB7AE08002143658709800054; reg [3:0] nibbles[0:256]; (Enviroment is Xilinx/Linux ISE xst) I would prefer a vendor neutral way.... but if it's not possible tweaks are ok :)Article: 127482
On Thu, 27 Dec 2007 10:37:49 -0800, Duane Clark <junkmail@junkmail.com> wrote: >Brian Drummond wrote: >> On Wed, 26 Dec 2007 07:06:39 -0800 (PST), John Adair >> <g1@enterpoint.co.uk> wrote: >> >>> The big advantage of using the core generator is to get a logic >>> function that is difficult to infer in a language like VHDL or >>> difficult to attain the required performance. >> >> Or which is easy to infer in a language like VHDL, but for which the >> synthesis tools don't support particularly well. >> >> A recent case here was a 256-element lookup table, inferred as a >> constant array initialised via a function call (which called other >> functions to create the data, and others to manipulate it into fixed >> point format, round it, etc) A bit convoluted but too fast to see in >> Modelsim.. > >For that kind of a task, I prefer to write C code that directly >generates a VHDL package file with a constant array. I find it a lot >easier to code and debug (and change), and the level of C knowledge >required is not very high. I avoid C wherever possible, though unfortunately it isn't always possible. If I had to do this again, I would also generate a package, but using VHDL. As far as simulation was concerned, it worked beautifully; and changes were undoubtedly easier than dropping into C to re-create the package; and adding package output from VHDL would be easy. There are limits to escaping from low-level hardware generation to higher level behavioural design creation; but mostly they are not inherent in the language, and they are slowly being pushed further back. This was partly an experiment to find out how far they have been pushed; not very far yet, unfortunately. - BrianArticle: 127483
On Thu, 27 Dec 2007 04:29:22 -0800 (PST), Uncle Noah <nkavv@skiathos.physics.auth.gr> wrote: >Hi Brian > >thanks for your answer. A question: > >> Instantiate the module in the top level design and add a "box type" >> attribute set to "black_box" (for syntax see e.g.http://www.xilinx.com/support/answers/9838.htm >> After synthesis, check the synthesis report; your module should appear >> as a black box (or primitive component). > >Actually, the black-box module is deep in the hierarchy. The hierarchy >is something like: > >level0: /top-level >level1: /top-level/foo >level2: /top-level/foo/bar > >bar is the black-box module. > >Does your answer apply for this case too? Yes - BrianArticle: 127484
On Thu, 27 Dec 2007 04:33:23 -0800 (PST), Uncle Noah <nkavv@skiathos.physics.auth.gr> wrote: >Hi >I mean is it possible to run final timing analysis (e.g. after par) >for the entire design (with the black-box included as proper). > After PAR, the black box IS included as proper. Translate (NGDbuild) does that, as I explained earlier. - BrianArticle: 127485
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:2sn9n3907b7fmtqglonpglgj8ljt41q2fo@4ax.com... > On Thu, 27 Dec 2007 10:37:49 -0800, Duane Clark <junkmail@junkmail.com> > wrote: > <snip >>> A recent case here was a 256-element lookup table, inferred as a >>> constant array initialised via a function call (which called other >>> functions to create the data, and others to manipulate it into fixed >>> point format, round it, etc) A bit convoluted but too fast to see in >>> Modelsim.. >> >>For that kind of a task, I prefer to write C code that directly >>generates a VHDL package file with a constant array. I find it a lot >>easier to code and debug (and change), and the level of C knowledge >>required is not very high. > > I avoid C wherever possible, though unfortunately it isn't always > possible. If I had to do this again, I would also generate a package, > but using VHDL. > > As far as simulation was concerned, it worked beautifully; and changes > were undoubtedly easier than dropping into C to re-create the package; > and adding package output from VHDL would be easy. > > There are limits to escaping from low-level hardware generation to > higher level behavioural design creation; but mostly they are not > inherent in the language, and they are slowly being pushed further back. > This was partly an experiment to find out how far they have been pushed; > not very far yet, unfortunately. > Keep in mind though that those limits are most likely vendor dependent. I've used functions that manipulate reals to initialize constant arrays to produce lookup tables without any problems with vendor A...using vendor X or Syn, I'm still generating service requests to fix other deficiencies in their tool that breeze right through with A. Doesn't help you if you're commited to vendor X, but if you're not, it might. KJArticle: 127486
Eric, these are very good points, and we will consider them when we refurbish TechXclusives. It's nice to be part of a newsgroup where intelligent people ventilate intelligent views. Happy New Year ! Peter Alfke =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Dec 27, 7:00=A0pm, Eric Smith <e...@brouhaha.com> wrote: > Peter Alfke wrote: > > The same considerations should be applied to application notes. Most > > of them that are 5 years old are more amusing than enlightening. > > I've found very useful info that is still relevant but much more than > five years old. =A0For example, your asynchronous clock switching > circuit, and Rob Weinstein's "flancter". =A0This is exactly the sort of > stuff that tends to get lost when someone gets a wild hair to "clean > up the web site". =A0Avnet dropped the flancter app note from their site > even though Rob tried to push them to keep it. =A0I've just used several > flancters in a new design this week, but I had to beg on the newsgroup > a few weeks ago to get people to send me a copy of the actual ap note. > (Thanks to everyone that helped out!) > > So what if 98% of old XL4000 ap notes aren't relevant? =A0It costs > almost nothing to keep them archived in a directory somewhere, and > the other 2% may contain useful design techniques that haven't been > rewritten for the Virtex 5. =A0These old app notes may help engineers > create new designs for paying customers. > > Since some XL4000 series parts are still in production, there may even > be engineers that occasionally have to maintain the designs or migrate > them to newer families. =A0Suppose the HDL source for something has an > explanation like "see the example on page 12 of XAPP271828", but the > app note and associated files are gone. =A0I've been through that > several time with other semiconductor vendors. > > I've always lamented how difficult it is to find data on old parts. > When data sheets started being supplied in PDF form in the late 1980s, > one of my friends said that the problem was solved and that the data > would be around forever. =A0I immediately disputed that point, and > predicted that electronic data would be even more emphemeral than > paper. =A0Twenty years of experience confirm that. > > Sigh.Article: 127487
On Thu, 2007-12-27 at 13:36 -0800, Duane Clark wrote: > root wrote: > > I installed Centos (linux) 5.1, Xilinx Webpack 9.2i.04, and EDK 9.2.02. > > > > However, when i launch 'xpsgui', I see a bunch of warning messages in my > > Try running just 'xps', rather than 'xpsgui'. Wow, don't I feel stupid. That was *exactly* the problem -- thank you!Article: 127488
On Fri, 2007-12-28 at 02:24 -0800, posedge52@yahoo.com wrote: > How does one initialize 'nibbles' in verilog the same way as 'longreg' > is initialised .. ? > > reg [1023:0] longreg = > 576'h555555555555555D00014AB7AE08002143658709800054; > reg [3:0] nibbles[0:256]; > > (Enviroment is Xilinx/Linux ISE xst) > > I would prefer a vendor neutral way.... but if it's not possible > tweaks are ok :) Have you tried? reg [3:0] nibbles[0:256]; initial begin nibbles[0] = <your_val>; nibbles[1] = <your_val>; ... endArticle: 127489
Eric Smith <eric@brouhaha.com> wrote: >Peter Alfke wrote: >> The same considerations should be applied to application notes. Most >> of them that are 5 years old are more amusing than enlightening. > >I've found very useful info that is still relevant but much more than >five years old. For example, your asynchronous clock switching >circuit, and Rob Weinstein's "flancter". This is exactly the sort of >stuff that tends to get lost when someone gets a wild hair to "clean >up the web site". Avnet dropped the flancter app note from their site >even though Rob tried to push them to keep it. I've just used several >flancters in a new design this week, but I had to beg on the newsgroup >a few weeks ago to get people to send me a copy of the actual ap note. >(Thanks to everyone that helped out!) > >So what if 98% of old XL4000 ap notes aren't relevant? It costs >almost nothing to keep them archived in a directory somewhere, and >the other 2% may contain useful design techniques that haven't been >rewritten for the Virtex 5. These old app notes may help engineers >create new designs for paying customers. > >Since some XL4000 series parts are still in production, there may even >be engineers that occasionally have to maintain the designs or migrate >them to newer families. Suppose the HDL source for something has an >explanation like "see the example on page 12 of XAPP271828", but the >app note and associated files are gone. I've been through that >several time with other semiconductor vendors. > >I've always lamented how difficult it is to find data on old parts. >When data sheets started being supplied in PDF form in the late 1980s, >one of my friends said that the problem was solved and that the data >would be around forever. I immediately disputed that point, and >predicted that electronic data would be even more emphemeral than >paper. Twenty years of experience confirm that. I fully second this. Especially Asian companies are keen on throwing out old datasheets. Back in the old days design companies used to have several cabinets filled with datasheet books. Nowadays they have hard drives full of datasheets. Websites like www.alldatasheet.com are very valuable; perhaps someone should start www.allappnotes.com. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 127490
Peter - Have you thought about opening the Tech Exclusives up to outside writers? For example, Antti had some nice examples of using SRL16's in interesting ways. Just a thought... John ProvidenzaArticle: 127491
Good idea. We would of course edit such contributions. I thought about this when the Flancter was mentioned. We will give credit, meticulously, and will try to avoid any copyright issues... (Too many lawyers) Peter On Dec 28, 11:05=A0am, johnp <johnp3+nos...@probo.com> wrote: > Peter - > > Have you thought about opening the Tech Exclusives up to outside > writers? > For example, Antti had some nice examples of using SRL16's in > interesting > ways. > > Just a thought... > > John ProvidenzaArticle: 127492
Hi, as explained in the note : http://focus.ti.com/lit/an/slva159a/slva159a.pdf .. the use of 3.3V for configuration results in a reverse current which needs to be sinked by the power supply .. can the two resistors R3 and R4 in Figure 1 at http://focus.ti.com/lit/ds/symlink/tps75003.pdf be used to sink this reverse current, or are a additional resistor required ?Article: 127493
Any load on the 2.5 V supply will sink current, but you have to scale these resistors to a much lower value to be meaningful. At 75 kilohm and 2.5 V, they sink only about 30 microamps. You may need 100 times more current. Peter Alfke On Dec 28, 1:37=A0pm, kislo <kisl...@student.sdu.dk> wrote: > Hi, as explained in the note :http://focus.ti.com/lit/an/slva159a/slva159a= .pdf > .. the use of 3.3V for configuration results in a reverse current > which needs to be sinked by the power supply .. =A0can the two resistors > R3 and R4 in Figure 1 athttp://focus.ti.com/lit/ds/symlink/tps75003.pdf > be used to sink this reverse current, or are a additional resistor > required ?Article: 127494
On 28 Dec, 18:17, root <r...@root.root> wrote: > On Fri, 2007-12-28 at 02:24 -0800, posedg...@yahoo.com wrote: > > How does one initialize 'nibbles' in verilog the same way as 'longreg' > > is initialised .. ? > > > reg [1023:0] longreg = > > 576'h555555555555555D00014AB7AE08002143658709800054; > > reg [3:0] nibbles[0:256]; > > > (Enviroment is Xilinx/Linux ISE xst) > > > I would prefer a vendor neutral way.... but if it's not possible > > tweaks are ok :) > > Have you tried? > > reg [3:0] nibbles[0:256]; > initial begin > nibbles[0] = <your_val>; > nibbles[1] = <your_val>; > ... > end I have seen that in some other post. The catch is that it will require reformatting of input data and becomes messy with frequent copy & paste from binary->text generator into source code. So I look for something where I can simply paste a hexstring right into code as a initialisation string. It doesn't make sense that it's alright for 1 bit wide arrays. But not for an 'n' wide array.Article: 127495
Hello everybody, Does anybody have any idea of a multiprocessor simulator. I have worked with uniprocessor architecture simulators based on simplescalar. Please suggest some CMP simulators which are more or less easy to build in Solaris/Linux machines. I would prefer using a CMP simulator based on extension of simplescalar but I am open to try my hands on anything new as well. Thanks in advance. KoustavArticle: 127496
On Sun, 2007-11-04 at 22:15 -0800, Eric Smith wrote: > Now that Xilinx has released Microblaze 7.0 with an optional MMU (in > EDK 9.2), has anyone started working on a Linux port? > > There's already a uClinux port to Microblaze with no MMU, but for > some applications it would be nice to run "normal" Linux. Lynuxworks already claims to have a (MMU) linux-port to Microblaze. http://www.lynuxworks.com/embedded-linux/embedded-linux.php Appnote ug258 is a precompiled demo of Bluecat Linux (Microblaze edition), for the Spartan3E Embedded Processing Kit (SP3E1600E.) I tried it out, but since I couldn't really build/compile/test my own applications on the embedded platform, it wasn't all that useful. (Basically, from a user perspective, looking through the RS232 port and ethernet-jack, it looks just like the prelodaed-uclinux demo.)Article: 127497
On Fri, 2007-12-28 at 20:39 -0800, posedge52@yahoo.com wrote:
> On 28 Dec, 18:17, root <r...@root.root> wrote:
> > Have you tried?
> >
> > reg [3:0] nibbles[0:256];
> > initial begin
> > nibbles[0] = <your_val>;
> > nibbles[1] = <your_val>;
> > ...
> > end
>
> I have seen that in some other post. The catch is that it will require
> reformatting of input data and becomes messy with frequent copy &
> paste from binary->text generator into source code.
> So I look for something where I can simply paste a hexstring right
> into code as a initialisation string. It doesn't make sense that it's
> alright for 1 bit wide arrays. But not for an 'n' wide array.
That's a limitation/idiosyncracy of Verilog. What you call a "1-bit
wide array" isn't really an array at all -- it's a sized-vector.
In Verilog, 2-D arrays are 'unpacked' arrays, what have all sorts
of painful baggage (as you've found out.)
Verilog-2001 allows multi-dimensional packed-arrays, but they won't
help you out here.
reg [3:0] useless_packed_array [0:39][0:15]; // Verilog-2001
integer i [3:0];
Systemverilog adds multi-dimensional UNpacked-arrays, which VHDL has
already supported since the dawn of time. Of course, Xilinx XST will
need to catch up and start supporting Systemverilog. (Altera Quartus
7.2 is already there!)
logic [7:0][3:0] unpacked_array; // Systemverilog
logic [7:0][3:0] unpacked_array2; // Systemverilog
initial unpacked_array = { 8'd1, 8'd2, 8'd3, 8'd4 };
initial unpacked_array2 = { default: '0 }; // all 0
integer [3:0] i;
^^^Ok I didn't check that in Modelsim -- someone will correct me if
that's wrong!
Article: 127498would someone like to give me some explanation about the difference when XAUI work as line side interface or in system interface? i am much puzziled about this concept. thanks a lotArticle: 127499
Hi members, I developed a Spartan-II (xc2s150-5pq208) based card. I also installed Xilinx Flash (xcf01s) there. Unfortunately when I detect these chips through JTAG, I found Xilinx Virtex (XCV150) device instead of Spartan- II (XC2S150). Rest of all is fine.. I have already done the following.. 1. Supplies are proper.. VCCO is 3.27V and VCCINT is 2.5V 2. Decoupling capacitors are there.. 0.1uF, 0.01uF (with most of power pins) and 47uF (with most of IO banks) Please anyone guide me... where is the mistake..? I am so grateful to you. Regards, Mir
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