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
Nicholas Weaver wrote: > > And THIS is why you should push the volatile solution. You have a > group of nonvolatile cells. The work in reverse engineering is going > to be a strong O(1) operation, as once it is done, it is simply a > matter of delidding the chip, probing in the right places, and reading > the results. > > Compared with the volatile solution: you are probably going to need to > do power or signal analysis on the encryption in action. Which means > you are probably going to need to add probes to the power/ground pins, > on a live board, without disrupting the power supply to the > configuration loader (which can be made even harder by potting the > FPGA with wires for the config voltage around it). I once learned how to use an electron microscope to probe signals on a chip. Once you figure out where the volatile bits are stored, wouldn't it be a simple matter to read them out with an electron microscope? Just pop the lid and stick the board (assuming it is small enough) under the scope. Probe it with a very low beam current and you should be able to see which bits are powered and which bits are off. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73501
Austin Lesea wrote: > > Further, > > We used: > > - low Vt transistors > - architectural improvements > - design improvements > - three oxides > > Why? Because we have to in order to meet our customer's needs. > > So do not compare us with a "gas guzzler" using old technology, old > design, and old architectures. > > No comparison, no contest. > > Austin Another well thought out discussion. Thanks Austin! ;) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73502
John_H wrote: > > Thanks for the dissertation. I'm afraid I miss your point, though. > > You've done a great job analyzing the tradeoffs from your view. As > engineers, I'm sure we can all appreciate that different tradeoffs are > "better" to different people from direct experience, knowledge, and > expectations (such as the troubles the industry had bringing up the low-K > dielectric). > > If parts from any manufacturer run hotter and cost more, the market will > gravitate away from those devices. If there are cool, fast, cheap, > feature-rich devices, we won't give a Vt whether there are extra process > steps or yield issues that could have produced a "better" part if another > approach were taken. > > Particularly troublesome to me is the conclusion that brand-X apparently has > their head up their triple oxide because non-FPGA vendors are implementing > their application-specific hardware on other processes. I don't SEE the > connection. > > I love to see input from all vendors, but I see more competitor negatives > than company positives here. Lets find out how good our new parts are, not > how bad their chips are. Maybe we're temporarily stuck in the political > mindset here in the US. This whole discussion in pretty pointless. As you say, a user does not care about *how* you make the chips, just how well they work. So when Austin and Dave argue about the tradeoffs in each vendor's choice of implementations, there is *no* point. The only useful info is (1) how much it costs (not even per LUT/SLICE/ALM but the real cost of the chip you need to implement *your* design *AFTER* you get through all the sales BS a dickering [which the engineer typcially does not get into]), (2) how long the lead times are, and (3) how long it takes to get your design to run in that part with the available software. Anything else is just noise... -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73503
Hi, When targeting the Cyclone II, the NIOS II/f configuration in SOPC builder doesn't seem to list support for either multipler, barrel-shifter or divide. Support for these only seems to be available when the target is a Stratix device. Is this correct? Is it not possible to get h/w multiply support on the Cyclone II? I'm using the eval version of NIOS II. Cheers, JonArticle: 73504
In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote: <snip> > This would make it possible to run standard > unix like Linux (MMU required) ... FYI: Linux is not unix. Also, linux does not require an MMU. http://www.uclinux.org --buddyArticle: 73505
Nicolas Matringe <nicolasmatringe001@numeri-cable.fr> wrote in message news:<414FD415.5080508@numeri-cable.fr>...
> Andre Bonin a écrit:
> > Ken McElvain wrote:
> >
> >> This loop should compile fine in Synplify.
> >
> >
> > I'me using quartus2. What is synplify?
>
> QuertusII doesn't like VHDL while loops. I replaced one with a for loop
> and an exit statement and it worked OK.
> I don't know if it is the same with Verilog while loops though.
I haven't used Synplify in ages, but I use Precision all the time.
According to the Precision manual, "Loops must be bounded by constants
or contain [a] @(posedge clk) statement."
The original poster's code:
integer X = 0;
always begin
while (X < 30) begin
X = X + 1;
end // while
end // always
has a couple of problems. First, if one were to simulate this, one
would see that it actually would execute in zero time. How SHOULD
this be implemented in hardware?
The initializer is ignored (think about it: what's the synthesizer
supposed to do with it?). The while statement isn't bounded like the
usual for loop:
for (x = 0; x < 30; x = x + 1) begin ... end //
Note the constants in that for loop, tho'. Say you had:
integer first, last;
for (x = first; x < last; x = x + 1) begin
those values aren't bounded, either, so the synthesizer wouldn't know
what to do with it.
The manual does say that the two loop conditions are ORed, so it one
modified the original poster's code as follows:
always @(posedge clk) begin
while (X < 30) begin
X = X + 1;
end // while
end // always
then one would expect things to "work." (It's a simple incrementer
that stops when it hits the value 30. Not very useful unless it can
be reset!)
Think hardware ...
-a
Article: 73506kofeyok wrote: > > Thanks for the reply rickman. > > That makes sence now. > I see that passing of values between modules is done using slv.. but you > can can convert (not cast) inside of each module. The signed port gives > non-synthesizable code. At least my simulator refuses to simulate. I don't know that it matters what types you use when passing signals between modules. Signed types should be just as synthesizable as any others. Also, simulators should work with code that is not synthesizable. My test benches are seldom synthesizable and they run just fine. I expect you have some other problem that changing the type is masking rather than fixing. The only issues with various types is when you want to mix them in assignments or other expressions. I don't think there are any arithmetic operators defined for slv while signed and unsigned do have operators such as +, -, <, >... Otherwise they are the same, no? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73507
Peter Alfke wrote:
>
> Mr Greenfield was not an anonymous spammer, he posted properly under his
> Altera address, and he was on-topic. Very much so, too much !
> He just made a bunch of unsubstantiated, opinionated, inflammatory and wrong
!------------------------------------------!
> statements, and he violated the spirit and the unwritten rules of this
> newsgroup. And I hope he and his ilk will never do that again.
I am confused, are you talking about Greenfield or Austin?
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 73508Buddy Smith wrote: > In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote: > <snip> > >>This would make it possible to run standard >>unix like Linux (MMU required) ... > > > FYI: > Linux is not unix. Also, linux does not require an MMU. > http://www.uclinux.org Is uclinux the same as Linux? I thought the kernel and the executables were considerably different.Article: 73509
Yes, you *are* missing something... ;) Don Golding wrote: > > Maybe I am missing something, but wouldn't you just drive all the chips with > one onboard clock then in your code trigger the processes on the rising > edge? > > Don > > "Leroy Tanner" <ikeepthespiritalive@freenet.de> wrote in message > news:cirft3$j4c$1@mamenchi.zrz.TU-Berlin.DE... > > Hello newsreaders, > > > > For a while I have been confronted with the following task which I find > > quite challenging but unfortuantely didn't manage to solve it, yet. > > What I want to do is to use 2-4 FPGAs (Xilinx Virtex 2 Pro) together on > > one > > printed circuit board (PCB). They are used to process a large amount of > > incoming serial data (data rates of several GHz's). My idea is to handle > > that data parallel by the 2-4 FPGAs. But now there arises the problem how > > to > > adequately split the data and how to synchronize the FPGAs among one > > another, in particular? > > Is it possible or first of all a realistic idea to synchronize multiple > > FPGAs in the GHz range? How can this be done without much protocoll > > overhead? I would like to do it without applying an extra transfer > > protocoll > > among the FPGAs just for that purpose! Up to this date I didn't find a > > proper solution, yet. > > Maybe someone can give me a hint? Any ideas how to solve that problem? > > > > Regards, Leroy Tanner > > > > -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73510
Pete Fraser wrote: > > "Chris Alexander" <info@bostonsemiconductor.com> wrote in message > news:376c28cd.0409220408.5da521d7@posting.google.com... > > Just so! There is more marketing jive going on here than just from > > Altera. Being new to this group, I thought this was a Xilinx only > > area until the "infamous posts" showed up. > > > > I look forward to the technical threads, but the hype from anyone > > (including Austin) I skip over. > > > > One more poster to add to the "skip-over-list". > > Much of Austin's stuff is worth reading. > Occasionally though, he goes into over-the-top marketing mode. That is true. Perhaps Austin should pass his posts through an editor who will make him write out the emotional marketing stuff. Then I can see his techical posts rising to the quality level of Dr. Howard Johnson perhaps. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73511
Leroy Tanner wrote: > But now there arises the problem how to > adequately split the data and how to synchronize the FPGAs among one > another, in particular? > Is it possible or first of all a realistic idea to synchronize multiple > FPGAs in the GHz range? How can this be done without much protocoll > overhead? I believe most important is to first latch the signals in the IOB to minimize clock skew problems. Otherwise, an external shift register to generate bit parallel signals for input to the FPGA. -- glenArticle: 73512
Rick, don't forget, there are ten layers of metal above the transistors that store the key or the configuration... Peter A >> > I once learned how to use an electron microscope to probe signals on a > chip. Once you figure out where the volatile bits are stored, wouldn't > it be a simple matter to read them out with an electron microscope? > Just pop the lid and stick the board (assuming it is small enough) under > the scope. Probe it with a very low beam current and you should be able > to see which bits are powered and which bits are off. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73513
Jim Stewart wrote: > Buddy Smith wrote: > >> In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote: >> <snip> >> >>> This would make it possible to run standard >>> unix like Linux (MMU required) ... >> >> >> >> FYI: >> Linux is not unix. Also, linux does not require an MMU. >> http://www.uclinux.org > > Is uclinux the same as Linux? I thought the kernel > and the executables were considerably different. 99% of the kernel code is identical. From 2.6 onwards, uClinux (ie nommu) support is integrated into Linus' root source tree. For 2.4 kernels, uClinux is a patch that *adds* to Linux, nothing is removed. In the microblaze port for example, we take drivers written by MontaVista for the PPC/V2Pro kernel, and drop them in directly. Some small modifcations are required usually due to differences in kernel configuration mechanisms, not fundamental architectural issues. From an application programming perspective, much of the time apps are source compatible between linux and uClinux. I recently took some ntp (network time protocol) tools and had then running on my microblaze uClinux board in under half an hour. No source code changes required. nommu means no fork(), you use vfork instead. Many Linux/Unix programs use the sequence fork()/exec() - this is easily ported to vfork. Other, more complex uses can be a bit trickier. pthreads works on uClinux platforms. uClinux uses a different executable file format (called flat binaries), rather than ELF. However, the build environment and tools automatically handles the creation of these files. Once your board has booted, they are just executables, same as any other. Read the following excellent article by Dave McCullough if you'd like to learn more about the differences (and lack thereof): http://www.linuxjournal.com/article.php?sid=7221 Regards, JohnArticle: 73514
..and dissolving them off with hydrofluoric acid while the chip's battery backed bit stays powered up would be a very neat trick indeed! Cheers, Syms. "Peter Alfke" <peter@xilinx.com> wrote in message news:BD773898.8C85%peter@xilinx.com... > Rick, don't forget, there are ten layers of metal above the transistors that > store the key or the configuration... > Peter A > > >> > > I once learned how to use an electron microscope to probe signals on a > > chip. Once you figure out where the volatile bits are stored, wouldn't > > it be a simple matter to read them out with an electron microscope? > > Just pop the lid and stick the board (assuming it is small enough) under > > the scope. Probe it with a very low beam current and you should be able > > to see which bits are powered and which bits are off. > > > > --Article: 73515
I just had a query from a potential client who has a large number of very old systems that they need to support. The systems use the XC4013e and XC4010e. Assuming that there is a synthesis tool that still supports the XC4000E family (I'm pretty sure that Synplify can still do it), will the current versions of map and par be able to place and route a 4000E design?Article: 73516
"mete" <mete@ieee.org> wrote in message news:acc68109.0409220755.6012e358@posting.google.com... > Hi, > > Can you provide me a code piece to use async. sram e.g. in spartan-3 > starter kit ? I could not get it work. > You may have found these already, but there are a few example applications available for download from the Xilinx Spartan-3 Starter Kit Board web site. http://www.xilinx.com/products/spartan3/s3boards.htm#RF In specific, the Digital Clock PCB Monitor design and the MicroBlaze Master System both read and write to the 1Mbyte of external SRAM on the board. The PCB Monitor design uses the free PicoBlaze 8-bit controller core. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 73517
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:414E7D8D.7C56BCE3@yahoo.com... [snip] > I have been meaning to send you an email to ask if the Spartan 3s are > supported for modular reconfiguration yet. How is that going? I seem > to recall that there were a couple of things that had to be resolved > before the work could even begin. One was a "bug" or some aspect of the > ISE software and the other was a work around for the fact that Spartan > 3s don't have any tristate buffers. Have either of these issues been > worked? How close are we to having a solution? The modular support using bus macros is not supported currently. It is supported via the "bitgen -r" approach, as described in the following Answer Record. Is partial reconfiguration supported on Spartan-3 devices? http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=18416 --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 73518
"B. Joshua Rosen" <bjrosen@polybus.com> wrote in message news:pan.2004.09.22.22.18.28.667446@polybus.com... > I just had a query from a potential client who has a large number of very > old systems that they need to support. The systems use the XC4013e and > XC4010e. Assuming that there is a synthesis tool that still supports the > XC4000E family (I'm pretty sure that Synplify can still do it), will the > current versions of map and par be able to place and route a 4000E design? > Oh, were it that easy. :-) The current version of the Xilinx software no longer supports the XC4000E family. Fortunately, the XC4000E and Spartan families are still supported via ISE Classic, freely downloadable from the web. http://www.xilinx.com/webpack/classics/spartan_4k/index.htm --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 73519
Rick, Good words to live by. I am concerned with: - quiescent power (which is a direct advantage to some, not all in V4) - performance in V4 (~5% faster in raw speed at slowest speed grade) something that is design dependent, and subject to lots of variations, so it is up to the software folks, and each individual to compare their design and make their own decision if it is a big item for them - yield (obviously, if it doesn't yield, it is a moot story for all concerned). Yield = cost to customer. Better cost, better yield. We have 1 M units of 90nm shipped in Spartan 3 (today's press release), so no issues there. - dynamic power savings (directly benefits almost everyone to have 1/2 the power and less in hardened block in V4 than in V2P). No BS: we are better in all of these categories. Why claim it, if we did not have data to show it is true? No marketing, great engineering by the IC Design group, fllowed by great engineering work by our verification and charaterization lab. Am I proud of the work we do? You bet: it is our contribution to the IC Design group, and the overall excellence of the product. I will try not to be too proud of the work, and clutter up my posts. Do I 'trash' S2? Absolutely not. Do I spread FUD? Nope (although I am guilty of subtle FUD on occason, but Peter usually keeps me honest....and I am working on it). Do I intentionally present the best, and not mention any mediocre or less than perfect stuff? Sure, don't we all? But if you want the errata list, it is something you get with ES delivery (or from your FAE prior to delivery -- who does their laundry in public? No one), and all I will say is that you can go and compare our errata with anyone else's anytime you want, and you make your own decision what is important to you. Austin rickman wrote: > John_H wrote: > >>Thanks for the dissertation. I'm afraid I miss your point, though. >> >>You've done a great job analyzing the tradeoffs from your view. As >>engineers, I'm sure we can all appreciate that different tradeoffs are >>"better" to different people from direct experience, knowledge, and >>expectations (such as the troubles the industry had bringing up the low-K >>dielectric). >> >>If parts from any manufacturer run hotter and cost more, the market will >>gravitate away from those devices. If there are cool, fast, cheap, >>feature-rich devices, we won't give a Vt whether there are extra process >>steps or yield issues that could have produced a "better" part if another >>approach were taken. >> >>Particularly troublesome to me is the conclusion that brand-X apparently has >>their head up their triple oxide because non-FPGA vendors are implementing >>their application-specific hardware on other processes. I don't SEE the >>connection. >> >>I love to see input from all vendors, but I see more competitor negatives >>than company positives here. Lets find out how good our new parts are, not >>how bad their chips are. Maybe we're temporarily stuck in the political >>mindset here in the US. > > > This whole discussion in pretty pointless. As you say, a user does not > care about *how* you make the chips, just how well they work. So when > Austin and Dave argue about the tradeoffs in each vendor's choice of > implementations, there is *no* point. The only useful info is (1) how > much it costs (not even per LUT/SLICE/ALM but the real cost of the chip > you need to implement *your* design *AFTER* you get through all the > sales BS a dickering [which the engineer typcially does not get into]), > (2) how long the lead times are, and (3) how long it takes to get your > design to run in that part with the available software. > > Anything else is just noise... >Article: 73520
In article <2re9nhF199f5gU1@uni-berlin.de>, Symon <symon_brewer@hotmail.com> wrote: >..and dissolving them off with hydrofluoric acid while the chip's battery >backed bit stays powered up would be a very neat trick indeed! >Cheers, Syms. And don't forget that the V4 is a flip-chip package, so you need to depackage and delid it without disrupting the power. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 73521
BlankHi, I have a problem generating the "hello" example in QuartusII V4.1 for excaliber (epxa1 chip with the ARM cpu). This project complied and linked without any errors in v3.0. In v4.1 (or v4.0), I keep getting a linking error - something to the effect "cannot load ld : -lgcc.." when I perform a software build. I do have the directory of libgcc in the path in the linker setup menu. The folks at Altera do not seem to have seen this problem. Anyone else has come across this? I think it may be in my setup. To make sure that I do not have some legacy effect (due to previous versions of Quartus), I installed v4.1 (with SP1) on a new machine, but to no avail. BTW, this is on M'soft XP machine. Any Ideas? Thanks -RaviArticle: 73522
nigelmerritt@hotmail.com (Nigel) wrote in message news:<cf7f0f95.0409211915.7d9f40e5@posting.google.com>...
> We have just started writing a small application on the NIOS IDE II
> (version 1.0.0, build 316). I want to develop it in C++, but it won't
> recognise C++ syntax, (class, new etc), so clearly I need to do
> something to enable C++, but I can't find anything. I have found
> similar problems on the forums/groups, but none with any answers. The
> closest one was to use "extern "C"{...} around the #includes, but this
> made no difference.
> Any help would be appreciated.
Now solved... it was simply that the 'main' file was created as a ".c"
file, not a ".cpp" (all template projects are for the NIOS).
Article: 73523Followup to: <cismeb$85u$1@news-int.gatech.edu> By author: Buddy Smith <buddy@tpac.gatech.edu> In newsgroup: comp.arch.embedded > > In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote: > <snip> > > This would make it possible to run standard > > unix like Linux (MMU required) ... > > FYI: > Linux is not unix. Also, linux does not require an MMU. > http://www.uclinux.org > However, if you take "Unix-like" as an adjectival phrase, and the parenthesis as definitional (therefore avoiding arguments about its validity), it makes sense: "This would make it possible to run the standard Unix-like Linux, i.e. the one which requires an MMU." Desipire ucLinux, there is clearly still a win in having an MMU for running Linux. -hpaArticle: 73524
Hi, I am working on a design where there are different components coded by different people. I am integrating all of these into a single top module. Different components have transitions on different edges of the clock.For eg: a FIFO in the design waits for the negative edge of the clock whereas another component waits for the positive edge of the clock... My question is...will it lead to synthesis problems if I make the code work keeping the different clock transitions or should I make all of them(including the subcomponents) transition on the same edge of the clock.. I am synthesizing to Virtex XC2V 4000 FPGA and am planning to download the bitstream and show a working proof Thanks, Hardware Engineer
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