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
Put me *SQUARELY* in category 1. You have a HW problem that demands a re-layout. The kludges presented here may work for quantity 1, but you will have trouble trying to build many of these. And this approach is wholly unacceptable for a product that will ship to customers. 'Deglitchers' are for mechanical switches, not clocks. There are some basic elements that must work on a digital circuit board, and the 'clock' falls into this category.Article: 99826
"Markus Kuhn" <n06W13+mgk25@cl.cam.ac.uk> wrote in message news:e0dqqp$99b$1@gemini.csx.cam.ac.uk... > "Frank" <frank@yahoo.com.cn> writes: > |> I am looking for textbook with detailed information on AES encryption > |> and decryption. I have Bernard Sklar's Digital Communications, but it > |> contains DES only. > > For a detailed textbook about AES by its designers, have a look at > > Joan Daemen, Vincent Rijmen: > The Design of Rijndael: AES - The Advanced Encryption Standard > Springer, 2002, ISBN 3540425802. > > Most newer entry-level cryptography textbooks (e.g., > Douglas R. Stinson's Cryptography: Theory and Practice, > 3rd edition) contain a couple of pages on AES. > > What textbook is best suited for you really depends on > your background and for what reason you want to learn > about AES (just implement it? start a PhD project to > attack it? teach a class?). > > Markus > > -- > Markus Kuhn, Computer Laboratory, University of Cambridge > http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain Well, my objective is to write a hardware enc/decryptor for AES in FPGA. I am reading the PDF files released on the AES website. <Announcing the ADVANCED ENCRYPTION STANDARD (AES)> Hope I can get a clue soon.Article: 99827
Hello John, > > We did my original #2 suggestion, a tapped delay line driven from the > pin, driving an r-s flipflop. Set the flop if all the taps are 1s, > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. > The delay line is a string of eight buffers, about 10 ns overall. > > We'd have done Peter's circuit if we'd learned of it sooner. > > It's interesting that my post evoked two classes of response: > > 1. It can't be done, don't do it, kluge the boards (also the official > Xilinx response!) > > 2. Yes, and here are my ideas on how you could do it/how I've already > done it/interesting asides. > That probably depends on what kinds of projects the individual responders usually work on. In my field (medical) I could lose my shirt if I did the digital de-glitcher thing. If it's an application where nothing bad can happen when it chokes or where that condition will always be signaled it might be different. But I wouldn't do it. Regards, Joerg http://www.analogconsultants.comArticle: 99828
I agree that the 80% effort is in the verification. That is why the verification tools have been improving so dramatically over the last decade, where RTL design tools hasn't really changed all that much. Vera, Specman, and now SystemVerilog Testbench are all nicer and higher level way of verifying designs. Constraint based Random Verification gets more bang for the buck out of your simulation dollar. They are still costly in runtime ( read : slow ), but are definately an improvement over the old style hand coded testbenches. Assertion Based Verification using OVA, OVL, PSL, SVA types are maturing and more mainstream, and this will definately help in the reuse of IP, however the cost of use is high because, this verification runs continuously in your simulation. In fact just a few temporal assertions added to some interface can half your runtime performance ( from my experience on a 2MGate microprocessor core). Static assertions are clearly more performance friendly but must more limited in there checking. I know companies like Real Intent have tools that try to use "Automatic formal" ( which extracts the assertions, and formally proves they are possible scenarios in which illegal behavior can be expressed) . This also seems like a good thing, unfortunately I have found that this type of work is typically done by the RTL designer, and increases his workload, not decreases. And the holy grail of "Spec -> RTL" tool still doesn't exist. But I agree we have more tools to get us closer. I still don't see there being any other way of describing large ASIC's in any other way than hierarchical hand coded RTL. And these tools that try to make it easier to verify, I haven't seen one yet, that actually implements your logic, because usually the designer is the one who knows what to optimize for : performance, speed, area, cost, manufacturability, testability . . . So, at the end of the day, I don't think the job of the RTL designer is going away any time soon. In fact most of these tools still require more code to be written to describe the correct behavior. I don't think these technology is driving RTL designers out of work. -ArtArticle: 99829
"Frank" <frank@yahoo.com.cn> wrote in message news:442b3120$1@news.starhub.net.sg... > > Well, my objective is to write a hardware enc/decryptor for AES in FPGA. > I am reading the PDF files released on the AES website. > <Announcing the ADVANCED ENCRYPTION STANDARD (AES)> > Hope I can get a clue soon. > Hi Frank, You may be able to get a clue from http://www.opencores.org/projects.cgi/web/aes_core/overview where someone's already done an IP core! HTH, Syms.Article: 99830
John, I assume before this that the clock was going into a global clock pin? If so, how do you deal with losing the low skew chip-wide network now that you're coming in on a standard I/O pin? Take care, Rob "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:i88l229so8qheephlt41crc0v7e5ebch3r@4ax.com... > On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote: > >> >>John Larkin wrote: >>> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote: >>> >>> >>> >So the Fpga to Fpga routing worked - good. >>> >>> That's not what we did. We designed a clock deglitcher to go inside >>> the FPGA. >> >>Enough propagation delays to cover the dwell at the switching >>threshold, and a state machine to make sure that the clock only changes >>state once in that interval? > > > We did my original #2 suggestion, a tapped delay line driven from the > pin, driving an r-s flipflop. Set the flop if all the taps are 1s, > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. > The delay line is a string of eight buffers, about 10 ns overall. > > We'd have done Peter's circuit if we'd learned of it sooner. > > It's interesting that my post evoked two classes of response: > > 1. It can't be done, don't do it, kluge the boards (also the official > Xilinx response!) > > 2. Yes, and here are my ideas on how you could do it/how I've already > done it/interesting asides. > > John > >Article: 99831
John Larkin wrote: > On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote: > > >>John Larkin wrote: >> >>>On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote: >>> >>> >>> >>>>So the Fpga to Fpga routing worked - good. >>> >>>That's not what we did. We designed a clock deglitcher to go inside >>>the FPGA. >> >>Enough propagation delays to cover the dwell at the switching >>threshold, and a state machine to make sure that the clock only changes >>state once in that interval? > > > > We did my original #2 suggestion, a tapped delay line driven from the > pin, driving an r-s flipflop. Set the flop if all the taps are 1s, > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. > The delay line is a string of eight buffers, about 10 ns overall. > > We'd have done Peter's circuit if we'd learned of it sooner. > > It's interesting that my post evoked two classes of response: > > 1. It can't be done, don't do it, kluge the boards (also the official > Xilinx response!) > > 2. Yes, and here are my ideas on how you could do it/how I've already > done it/interesting asides. A couple of questions for those who are in 1), Would you use the Pin-Delay feature on a FPGA, to de-skew click lines from other devices ? If you are OK with that, suppose John now uses the same Pin-delay feature (chained) on his 'toggle rate governer' - is that then OK ? -jgArticle: 99832
On 29 Mar 2006 16:51:23 -0800, "mike_la_jolla" <mdini@dinigroup.com> wrote: >Put me *SQUARELY* in category 1. You have a HW problem that demands a >re-layout. The kludges presented here may work for quantity 1, but you >will have trouble trying to build many of these. Why? What we're doing is perfectly sound, and works exactly as expected. >And this approach is >wholly unacceptable for a product that will ship to customers. Too late, a bunch have already been shipped. Bit who gets to decide "unacceptable"? And who enforces it? >'Deglitchers' are for mechanical switches, not clocks. Is that an Federal law or something? Are all those millions of Sonet clock-recovery PLLs out there illegal? >There are some basic elements that must work on a digital circuit >board, and the 'clock' falls into this category. Right; it works fine now. JohnArticle: 99833
On Thu, 30 Mar 2006 01:17:10 GMT, Joerg <notthisjoergsch@removethispacbell.net> wrote: >Hello John, > >> >> We did my original #2 suggestion, a tapped delay line driven from the >> pin, driving an r-s flipflop. Set the flop if all the taps are 1s, >> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. >> The delay line is a string of eight buffers, about 10 ns overall. >> >> We'd have done Peter's circuit if we'd learned of it sooner. >> >> It's interesting that my post evoked two classes of response: >> >> 1. It can't be done, don't do it, kluge the boards (also the official >> Xilinx response!) >> >> 2. Yes, and here are my ideas on how you could do it/how I've already >> done it/interesting asides. >> > >That probably depends on what kinds of projects the individual >responders usually work on. In my field (medical) I could lose my shirt >if I did the digital de-glitcher thing. If it's an application where >nothing bad can happen when it chokes or where that condition will >always be signaled it might be different. But I wouldn't do it. > If your application is critical, one could argue that you are in fact obligated to do this to increase clock noise immunity. But we're just testing jet engines. JohnArticle: 99834
On Thu, 30 Mar 2006 02:03:20 GMT, "Rob" <robnstef@frontiernet.net> wrote: >John, > >I assume before this that the clock was going into a global clock pin? If >so, how do you deal with losing the low skew chip-wide network now that >you're coming in on a standard I/O pin? > >Take care, >Rob We now treat that pin as a regular input. After the deglitch logic, we pipe it into a global clock buffer, and it becomes the new 16 MHz master clock for the whole chip. JohnArticle: 99835
The PLCC Spartan/SpartanXL is NOT going to be the least costly. Xilinx no longer supports them. To synthesize, you'll need FPGA Express, and the last time I checked, it ran about $15,000.00 - 15K will buy a lot of time at your local stuffing house. "If it ain't supported in a current web-pack, don't use it."Article: 99836
The open source FpgaC project is looking for a few more developers in
various technology areas and skill levels. One project is updating the
generic LUT only technology mapping code that came with TMCC written a
decade ago, to a newer algorithm that better fits current technology
FPGAs today.
We've started this with several changes, and there is lots more fun
work to go.
The next part of this project, is given a truth table, is to find the
best way to decompose it into LUT's and MUX's. This project is
available for anyone that would like it. Since it's pretty issolated
from the compiler guts, and will be implemented in the device specific
output functions, it's a good project for someone wanting to get their
feet wet as an internals developer.
This isn't exactly easy to do well, but almost any implementation will
be better than the current fitting strategy for LUT only mapping, so
refinement can happen over time as the developers skills build in this
technology area. This is an area of active and competitive research, so
it might make an interesting undergraduate project, or graduate level
thesis.
Interesting reading is related to the Quine-McCluskey algorithm
(implemented in FpgaC) and general logic synthesis algorithms. See:
http://www.eecs.berkeley.edu/~alanmi/abc/
http://embedded.eecs.berkeley.edu/Respep/Research/mvsis/software.html
http://www.eecg.toronto.edu/~jzhu/releases/fbdd/info_web/index.html
http://www.ecs.umass.edu/ece/labs/vlsicad/bds/bds.html
http://service.felk.cvut.cz/vlsi/prj/BOOM/
Good resume builder project for someone interested in EDA software
tools as a job.
http://sourceforge.net/projects/fpgac
Have fun,
John
Article: 99837Hi Jon, The VHDL for the Xilinx BRAM controller is provided with the EDK. Look in C:\EDK\hw\XilinxProcessorIPLib\pcores\plb_bram_if_cntlr_v1_00_b (or wherever you installed the EDK on your machine). There's a similar core for the OPB, and a base library in bram_if_cntlr_v1_00_b You should be able to copy and merge the appropriate folders and use it as a custom core in your own EDK project. You'll probably want to pick a new core name instead of plb_bram_if_cntlr to avoid confusion. Be sure to rename all of the appropriate files. (I found this to be a big pain to get right if you've never made a custom core before. You could use the Xilinx wizard to create an empty PLB or OPB core and use it as an example of their naming and version number conventions.) The BRAM is not instantiated as part of the controller. You use the separate bram_block core in the EDK for it. You should be able to copy that core as well and modify it if needed. Also, you should be able to find examples of how the controller and BRAM core are connected. There are plenty of basic examples of a PowerPC, PLB bus, controller, and BRAM memory available online. Hope this helps, Jeff "Jon Anderson" <jon@idcomm.com> wrote in message news:ee99836.-1@webx.sUN8CHnE... > Greetings. > > I am looking to figure out a way to modify an existing BRAM controller > (connected to either OPB or PLB) to add ECC capabilities. I am using EDK > 7.1i, and it appears that controllers instantiated there cannot be > modified. I have looked at Xilinx XAPP645 and understand how it works, but > can't find a way to insert the VHDL into an existing controller. > > Basically, I'm trying to break the connection at PORTA such that the data > will run through the ECC encoder to the BRAM, but the address and control > lines are still intact (and connected to to the BRAM blocks). It seems > like it should be a fairly straightforward exercise, but I have had zero > success. > > The other part of the issue is that BRAM itself appears to be instantiated > as part of the controller, so I also need to have a way to support the > extra data as well. I appear to be getting BRAMs with the additional bit > for parity data, but have no good way to access it. > > This is being done on a Virtex-II Pro, and I'm connecting to the PPC core. > However, I don't think this is application-specific, since I should be > able to do the same thing with a Microblaze, for example. > > Thanks!Article: 99838
Karl wrote:
> Karl wrote:
>
> > Look at the EP2C35F672 based development kits and swap the device. You
> > will loose around 50 I/O's on the EP2C70 but if you are lucky the DDR
> > interfaces remain OK (did not check this)
> >
> > Happy soldering !
> >
> > Karl.
>
> I checked... The Altera DSP development kit is made for 2C35 2C50 and
> 2C70. The additional I/O's on the 2C35 and 2C50 are not used and you
> should be able to do this trick.
>
> Karl.
I requested a quote from Altera with the EP2C70 soldered on
the EP2C35
DSP development board , but they were not interested. I also requested
a qoute from TerAsic , but they also did not respond.
I thought that removing the EP2C35 from the board would be
too risky.
However, I did buy the Terasic DE2 EP2C35 board with the EP2C35 for
$495.
Bill Hanna
Article: 99839fpga_toys@yahoo.com wrote: > The open source FpgaC project is looking for a few more developers in > various technology areas and skill levels. One project is updating the > generic LUT only technology mapping code that came with TMCC written a > decade ago, to a newer algorithm that better fits current technology > FPGAs today. > We've started this with several changes, and there is lots more fun > work to go. > > The next part of this project, is given a truth table, is to find the > best way to decompose it into LUT's and MUX's. This project is > available for anyone that would like it. Since it's pretty issolated > from the compiler guts, and will be implemented in the device specific > output functions, it's a good project for someone wanting to get their > feet wet as an internals developer. > > This isn't exactly easy to do well, but almost any implementation will > be better than the current fitting strategy for LUT only mapping, so > refinement can happen over time as the developers skills build in this > technology area. This is an area of active and competitive research, so > it might make an interesting undergraduate project, or graduate level > thesis. > > Interesting reading is related to the Quine-McCluskey algorithm > (implemented in FpgaC) and general logic synthesis algorithms. See: > > http://www.eecs.berkeley.edu/~alanmi/abc/ > > http://embedded.eecs.berkeley.edu/Respep/Research/mvsis/software.html > > http://www.eecg.toronto.edu/~jzhu/releases/fbdd/info_web/index.html > http://www.ecs.umass.edu/ece/labs/vlsicad/bds/bds.html > http://service.felk.cvut.cz/vlsi/prj/BOOM/ > > Good resume builder project for someone interested in EDA software > tools as a job. > > http://sourceforge.net/projects/fpgac > > Have fun, > John Hi John, I have to ask are you the head developer of this project? Also I see University of Toronto is heavily involved with your project. While I do not go to that school, I go to a lesser known University in the area, do you have any contacts there? Thanks -IsaacArticle: 99840
Karl wrote: > Karl wrote: > >> Look at the EP2C35F672 based development kits and swap the device. You >> will loose around 50 I/O's on the EP2C70 but if you are lucky the DDR >> interfaces remain OK (did not check this) >> >> Happy soldering ! >> >> Karl. > > I checked... The Altera DSP development kit is made for 2C35 2C50 and > 2C70. The additional I/O's on the 2C35 and 2C50 are not used and you > should be able to do this trick. Thanks for checking Karl, but I know I could not do this myself and paying for someone to do the pull and then add the 2C70 is starting to sound expensive. I can't justify spending a whole lot more than $1000. I'm looking into the promising LatticeECP2, but it sure would have been nice if Xilinx would add support for the 3S5000 (Xilinx, hint hint :) If anyone knows of any 2C70 boards, do let us know. TommyArticle: 99841
Isaac Bosompem wrote: > I have to ask are you the head developer of this project? I founded the FpgaC project, and drive it to some extent, but view it as a group effort. > Also I see University of Toronto is heavily involved with your project. > While I do not go to that school, I go to a lesser known University in > the area, do you have any contacts there? They have not been active in FpgaC, other than providing BSD licensed TMCC sources we used as a foundation. I exchange emails with the original author from time to time, but he is too busy in other projects to participate at this time.Article: 99842
JJ wrote: > Precisely, anyone who has done FPGA cpu design knows how limiting FPGAs > can be .ie 20-120MHz is typical for unfriendly architectures. > > If your not in that very small club of Intel, AMD, IBM, then even full > custom is also pretty limiting by the extreme expense of it all. The > top tier may still be directly instantiating transistors as well as > flops. But then transistor level design is still able to significantly > outperform standard cell logic using a variety of mostly nmos > differential techniques, I guess by a factor of 3. At Suns level, they > are much closer to full standard cell with synthesis with a fraction of > the clock of P4s but they make up for it by going to massive threading > and latency hiding to bring out the throughput. I think you're being overly generous to Sun here. > Theres the clue there. The same can be done in FPGA cpu for > multithreading architecture to simplify the design so that you are not > limited to 32b carry ripples. In my Transputer design I was seeing > 300MHz on the PEs because it could use 2 clocks per basic opcode and > used 8 clocks for 4 thread instructions, alot of cycle limiting logic > just vanishes, ie no hazard logic or register forwarding paths. The > hardware design of the MMU hasn't started so there is nothing to > release. I think this is pretty much well known, although no less true. However, as Amdahl put it, "What would you rather use to plow a field? Two oxen or a thusand chicken?". In your world things are of course different as you're coming from a paradigm of many many threads. However the rest of the world is only slooowly moving to multiple threads. It is interesting though that by giving up half the speed on single thread performance, you can gain 3-4 times the throughput for free. I'll definitely play with that. > I am surprised that we haven't seen alot more native FPGA MTA designs > though,. In addition to what I mentioned, there's surely more inertia issues and the complication of multi-threaded software (assuming you can even take advantage of it). My $0.01 TommyArticle: 99843
Thanks for the info. Yes... I'm trying to test some stuffs where each processor have some tasks to complete - a shared memory space will be used to communicate between them. i can create the bitstream and download through the jtag cable, though - i was thinking of making it more 'standalone' by just booting from the CF card.Article: 99844
How can one synthesize their Verilog code into FPGA SLICEs without doing PAR? I want the code to synthesize into SLICEs, not the lower-level LUTs/MUXs/FFs (which is what a "Generate Post-Map Simulation Model" in Xilinx ISE gives me). Ideally the output of the synthesis would almost exclusively consist of SLICEs. Thanks for your help, YannisArticle: 99845
Jean-Francois, follow the instructions in the ML403 Reference Design Users Guide (pg 39). In particular, create the board support package with the Linux MLD and use the patch_linux script in the linux sub-directory of the ML403 reference design. The patch sets bits 1 and 3 in CCR0 which is required for ES silicon, i.e. silicon where the PPC405 has a PVR of 0x20011430. After applying the patch the problem will be gone. - Peter Links: - ML403 Web Page: http://www.xilinx.com/ml403 - ML403 Users Guide: http://www.xilinx.com/bvdocs/userguides/ug082.pdf - ML403 reference design: http://www.xilinx.com/products/boards/ml403/files/ml403_emb_ref_ppc_81.zip jfh wrote: > Hi, > > I have been trying to port Linux on the ML403 board using the 2.4 devel > tree downloaded from montavista site using rsync.The compilation goes > fine with the modifications of some source files and makefiles after > copying the BSP generated from EDK 7.1 (I used some BYU website advice > about porting Linux on XUV2P board). I manage to download the Linux > kernel via xmd, the kernel boots but it has a problem and an exception > 0400 seems to occur. Did anyone try the same method and managed it > correctly ? Does anyone have an idea as to why I have this exception ? > How could I investigate this issue not being an expert in Linux but > just trying to understanding what is going on ? > > Best regards, > > JF >Article: 99846
In article <1143687230.719515.136950@j33g2000cwa.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >The next part of this project, is given a truth table, is to find the >best way to decompose it into LUT's and MUX's. What format is the truth table in? (BLIF, PLA, some other internal data structure) So is this the tech mapping step? You've already created the truth table that represents some part of the design and you need to map it into the underlying architecture. Sounds interesting. >This project is >available for anyone that would like it. Since it's pretty issolated >from the compiler guts, and will be implemented in the device specific >output functions, it's a good project for someone wanting to get their >feet wet as an internals developer. > >This isn't exactly easy to do well, but almost any implementation will >be better than the current fitting strategy for LUT only mapping, so >refinement can happen over time as the developers skills build in this >technology area. This is an area of active and competitive research, so >it might make an interesting undergraduate project, or graduate level >thesis. > >Interesting reading is related to the Quine-McCluskey algorithm >(implemented in FpgaC) and general logic synthesis algorithms. See: > > http://www.eecs.berkeley.edu/~alanmi/abc/ Ah, yes, Alan is on the cutting edge with this And-Inverter Graph stuff. He's also a very good programmer. Can you make use of what is already in ABC? While I would hesitate to use code from some other university projects that have appeared in the past, I would not hesistate to use Alan's code; it's generally engineered very well. PhilArticle: 99847
Hi I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone have any tips for the placement of the bypass caps. I want to use 0603 caps and normal PTH vias. I can see that it might get a bit crowded trying to position a lot of caps under the device near to the power pins with all those vias. Cheers JonArticle: 99848
imavroid schrieb: > How can one synthesize their Verilog code into FPGA SLICEs without > doing PAR? I want the code to synthesize into SLICEs, not the > lower-level LUTs/MUXs/FFs (which is what a "Generate Post-Map > Simulation Model" in Xilinx ISE gives me). Ideally the output of the > synthesis would almost exclusively consist of SLICEs. Clustering these components into slices is already a partial placement. It is controversial whether inital clustering helps or hurts placement. (At least it helps the tool runtime) IIRC the ISE synthesis tool has an option to pack LUTs to slices. If you turn it on the information which LUTs belong to the same slice must be in one of the files generated. You can than simply assign the muxes and flip-flops to the same slices as the LUTs driving them and have a netlist of Slices. Kolja SulimmaArticle: 99849
A good development board (Avnet, Insight, Xilinx) to look at, can give you some ideas. Aurash maxascent wrote: > Hi > > I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone > have any tips for the placement of the bypass caps. I want to use 0603 caps > and normal PTH vias. I can see that it might get a bit crowded trying to > position a lot of caps under the device near to the power pins with all > those vias. > > Cheers > > Jon
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