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
Drake, You can take a look at Xilinx's high speed DES and Triple DES app note at http://support.xilinx.com/apps/virtexapp.htm#appnotes This app. note also comes with both VHDL and Verilog reference designs. If you are not concerned much about performance refer the following free IP providers for DES VHDL source code. http://www.opencores.org/projects http://www.free-ip.com/DES/index.html For Xilinx's PCI core solution, refer http://www.xilinx.com/pci/ Hope this helps !!! -Vikram drake wrote: > i am looking for VHDL to implement cryptographic cyphers in an FPGA, > and an FPGA with a PCI interface. does anybody have any ideas? > > --drakeArticle: 40676
drake wrote: > i am looking for VHDL to implement cryptographic cyphers in an FPGA, > and an FPGA with a PCI interface. does anybody have any ideas? > > --drake www.opencores.orgArticle: 40677
The block RAMs do add a challenge, but with careful design you can get them to run quite a bit faster than 115 MHz in a -6. I have a -7 design where one port (the write port at that) is running at 240 Mhz. The -6 should be able to get pretty close to 200 MHz...if you are really careful with the BRAMs. AFAIK, the rijndael algorithm doesn't use carries, so the bottle neck is going to be the block rams. Even at the 200 MHz, there are some tricks you can play to keep the BRAM from being the bottleneck. Nicholas Weaver wrote: > In article <MNsj8.27108$af7.22802@rwcrnsc53>, > Kevin Neilson <kevin_neilson@removethis-yahoo.com> wrote: > >Yeah, I read this article. It's pretty weak. There will come a day when we > >will write HDL at such a level of abstraction we won't even need to know > >what a CLB looks like. That day is a long long way off. The tragedy is > >that some managers believe this hype and allocate valuable resources to it, > >ushering in a wave of weak, bloated, 50-levels-of-logic desgins. > > And if they don't need to worry about the bloat and slowdown, there is > no problem. > > My classic example: > > An academic implementation of a Rijndael core relies heavily on HDL > synthesis, and uses an 8 stage pipeline for the single round. It ran > at 100 MHz (according to static timing analysis) on a Virtex-6, using > 2000 slices and 8 BlockRAMS, with expanded subkeys stored in > Luts-as-ram. 1.2 Gbps throughput on nonfeedback modes, 150 Mbps > throughput on feedback modes. > > My implementation relied heavily on hand placing and understanding the > target architecture. It uses a 5 stage pipeline for the single > round. It runs at 115 MHz (according to static timining analysis) on > a Spartan II-5, using 800 slices and 10 BlockRAMs[1], with subkeys > computed on the fly. 1.3 Gbps throughput on nonfeedback modes, 260 > Mbps throughput on feedback modes. Ray Andraka probably could have > added another 5-10% improvement [2]. > > So, by using a synthesis methodology instead of programming to the > device, there is an ~10% penalty in throughput on nonfeedback modes, a > ~70% penalty in throughput on feedback modes, and a ~60% penalty on > area. > > If these costs don't matter, then synthesis worked fine. If costs > DOES matter, then synthesis failed hideously, and someone who was > doing this as part of a product would have to call one of the many > FPGA expert consultants to have it done right. > > [1] The extra 2 BlockRAMs were for the sboxes in the > subkey-generation. > > [2] Based that some of my design decisions were done on gut feel and > in combination with other bits. It may be possible to shave off a > cycle without hurting the clock TOO much, but I doubt it, but it may > be possible to squeeze a little bit better with some better balancing, > but it's hard to get much faster when you are hitting the BlockRAMs. > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40678
In article <cfd3bf0a.0203121206.14b6425b@posting.google.com>, drake <drake1337@hotmail.com> wrote: >i am looking for VHDL to implement cryptographic cyphers in an FPGA, >and an FPGA with a PCI interface. does anybody have any ideas? How much performance do you want? How much area? What FPGA? Why VHDL and not Verilog or schematic? And what cipher? The only symmetric key ciphers you should even consider are AES/Rijndael and 3DES. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40679
hi, In Quartus II , is the timing simulation after compilation a good indication of the speeds seen by a design in the actual FPGA ? If not what would I need to do to get a correct estimate of the timing ? What about routing delay estimates when the design gets mapped to the FPGA ? Are they accounted for in any way in the timing estimation process ? Thanks, PrashantArticle: 40680
MegaPowerStar wrote:
> Is there any equivalent verilog LPM/ALTPM function module from altera
> for xillinx dualport ram block RAMB4_S16_S16 module.The currently
> available DPRAM functions from altera(like
> LPM_RAM_DP,ALTSYNCRAM,ALT3PRAM) do not match the above xillinx DPRAM
> module.
> If not how can I implement the DPRAM in altera device.
Altera dpram has one just one read and one write port.
The following code snippet uses the ram this way and will infer a
DPRAM_16_8_256_6_0 for altera, or a
RAM_B4_S16_S16 for xylinx (leo ties off extra read and write controls)
-- Mike Treseler
-----------------------------------------------------------
. . .
constant mem_size : natural := 2**add_length;
type mem_type is array (mem_size-1 downto 0) of
std_logic_vector (dat_length-1 downto 0);
subtype ptr_type is unsigned(add_length-1 downto 0); -- unsigned wraps
signal mem : mem_type;
signal we : std_ulogic; -- write signal to block ram
signal rd_head_ptr : ptr_type; -- both _ptr must init same
signal wr_tail_ptr : ptr_type; -- each counts up appropriate cycles
begin
-------------------------------------------------------------------------------
-- Leo infers ram_dq_da_inclock_out_clock_16_8_256 from this template
-- for Virtex, this makes a RAM_B4_S16_S16 library XCV
-- for Apex, this makes a DPRAM_16_8_256_6_0 interface LPM library OPERATORS
-------------------------------------------------------------------------------
ram_access : process (clk)
begin
if rising_edge(clk) then
if we = '1' then
mem(to_integer(wr_tail_ptr)) <= data_i; -- raw address
end if;
data_q <= mem(to_integer(rd_head_ptr)); -- mem data after pop low
end if;
end process ram_access;
. . .
Article: 40681rickman <spamgoeshere4@yahoo.com> wrote in news:3C8D8F19.108838BE@yahoo.com: > I need to implement a two wire interface used on a Cypress CY22393 clock > chip. The data sheet simply refers to it as "industry-standard > signaling". The two signal names are SDAT and SCLK. They give no info > on the logic or the timing of the interface. When they don't pay Philips for the license they refer indirectly to I2C. See the I2C spec. at www.philips.com. It's a pig-simple hardware protocol. Well at least if you're doing single master anyhow. - MarkArticle: 40682
Prashant wrote: > In Quartus II , is the timing simulation after compilation a good > indication of the speeds seen by a design in the actual FPGA ? If you mean the static timing analysis and you have a synchronous design, then yes. > What about routing delay estimates when the design gets mapped to the > FPGA ? Are they accounted for in any way in the timing estimation > process Same answer. -- Mike TreselerArticle: 40683
Nick brought to my attention that he was referring to the 5v Virtex, I instinctively saw the -6 and assumed VirtexE. Not having the luxury of using the fastest speed grades, I am not sure of the numbers off hand for the 5v virtex, but it isn't that far different than the E-6. The near 200 MHz number assumes you avoid using the WE and ENA similar to what I have posted here before. Ray Andraka wrote: > The block RAMs do add a challenge, but with careful design you can get them to > run quite a bit faster than 115 MHz in a -6. I have a -7 design where one port > (the write port at that) is running at 240 Mhz. The -6 should be able to get > pretty close to 200 MHz...if you are really careful with the BRAMs. AFAIK, the > rijndael algorithm doesn't use carries, so the bottle neck is going to be the > block rams. Even at the 200 MHz, there are some tricks you can play to keep the > BRAM from being the bottleneck. > > Nicholas Weaver wrote: > > > In article <MNsj8.27108$af7.22802@rwcrnsc53>, > > Kevin Neilson <kevin_neilson@removethis-yahoo.com> wrote: > > >Yeah, I read this article. It's pretty weak. There will come a day when we > > >will write HDL at such a level of abstraction we won't even need to know > > >what a CLB looks like. That day is a long long way off. The tragedy is > > >that some managers believe this hype and allocate valuable resources to it, > > >ushering in a wave of weak, bloated, 50-levels-of-logic desgins. > > > > And if they don't need to worry about the bloat and slowdown, there is > > no problem. > > > > My classic example: > > > > An academic implementation of a Rijndael core relies heavily on HDL > > synthesis, and uses an 8 stage pipeline for the single round. It ran > > at 100 MHz (according to static timing analysis) on a Virtex-6, using > > 2000 slices and 8 BlockRAMS, with expanded subkeys stored in > > Luts-as-ram. 1.2 Gbps throughput on nonfeedback modes, 150 Mbps > > throughput on feedback modes. > > > > My implementation relied heavily on hand placing and understanding the > > target architecture. It uses a 5 stage pipeline for the single > > round. It runs at 115 MHz (according to static timining analysis) on > > a Spartan II-5, using 800 slices and 10 BlockRAMs[1], with subkeys > > computed on the fly. 1.3 Gbps throughput on nonfeedback modes, 260 > > Mbps throughput on feedback modes. Ray Andraka probably could have > > added another 5-10% improvement [2]. > > > > So, by using a synthesis methodology instead of programming to the > > device, there is an ~10% penalty in throughput on nonfeedback modes, a > > ~70% penalty in throughput on feedback modes, and a ~60% penalty on > > area. > > > > If these costs don't matter, then synthesis worked fine. If costs > > DOES matter, then synthesis failed hideously, and someone who was > > doing this as part of a product would have to call one of the many > > FPGA expert consultants to have it done right. > > > > [1] The extra 2 BlockRAMs were for the sboxes in the > > subkey-generation. > > > > [2] Based that some of my design decisions were done on gut feel and > > in combination with other bits. It may be possible to shave off a > > cycle without hurting the clock TOO much, but I doubt it, but it may > > be possible to squeeze a little bit better with some better balancing, > > but it's hard to get much faster when you are hitting the BlockRAMs. > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40684
I will like to know if there is a way to infer a parity
generator that uses Virtex's carry-chains rather than LUTs?
The reason I am asking this question is because when I synthesize a
parity generator, XST uses LUTs rather than carry-chains even if "XOR
Collapsing" option is checked (enabled).
I will like to conserve valuable LUTs, and use carry-chains because
carry-chains are rarely used in my design.
Will I have to use Virtex specific primitives to do so, or is there a
way to do so without using Virtex specific primitives?
IF I have to use Virtex specific primitives, how do I do it?
Or is this problem XST's fault, and do other synthesis tools handle XOR
stuff differently than XST?
The parity generator here I am talking about is a one that generates the
parity of 36-inputs for PCI bus.
Thanks,
Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)
Article: 40685Keith Brafford wrote: > "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3C8D8F19.108838BE@yahoo.com... > > I need to implement a two wire interface used on a Cypress CY22393 clock > > chip. The data sheet simply refers to it as "industry-standard > > signaling". The two signal names are SDAT and SCLK. They give no info > > on the logic or the timing of the interface. > > From their datasheet: > > The serial port uses industry-standard signaling in both stan-dard > > and fast modes. This section describes the unique fea-tures > > of the serial interface in this family of devices. > > The device address is a 7-bit value that is configured during > > Field Programming. By programming different device address-es, > > two or more parts can be connected to the serial interface > > and be independently controlled. The device address is com-bined > > with a read/write bit as the LSB and is sent after each > > start bit. > > This family of devices supports 1-byte memory addressing. > > The memory address is always sent after each Device Ad-dress/ > > Write bit combination. It describes the memory location > > within the device to be accessed. The memory address is in-cremented > > after each acknowledge, allowing sequential mem-ory > > access. > > To read a memory location, a write operation must be per-formed > > with the memory address to be read, and zero data > > bytes. This is followed by a repeated start bit and the Device > > Address/Read byte, after which the desired memory location > > is available for reading. > > -------------- > > That sounds like I2C. > > > The ATmega devices include an interface they call, TWI, for two wire > > interface. The signal names are SDA and SCL. Is this the same > > interface? Why can I not find info (in a Yahoo search anyway) on any of > > these names other than at Atmel or Cypress? Is this interface a real > > orphan? > > That definitely sounds like I2C. It's all over the place. > > --Keith Brafford Most likely I2C except the description above left out the ACK/NACK stuff that's the most awkward bit to implement. One good place to see a simple description of basic I2C operation is an SDRAM DIMM data sheet. The `serial presence detect' EEPROM is an I2C device.Article: 40686
> One of the reasons that "two wire" interfaces that are nominally IIC > are given a different name is that they aren't fully compatible with > the spec, even though they interwork in every practical way. > > Regards, > Allan. That may be partially true, but the primary reason that other manufacturers don't call their parts IIC compatible is that Philips would make them pay royalties to do so. Pretty much whenever you hear about two-wire interfaces, it's probably IIC compatible (more or less). michael brownArticle: 40687
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3C8E96E9.FA47D408@algor.co.uk... > > Most likely I2C except the description above left out the ACK/NACK stuff that's the most > awkward bit to implement. One good place to see a simple description of basic I2C operation > is an SDRAM DIMM data sheet. The `serial presence detect' EEPROM is an I2C device. Yeah...I think that the Cypress people were going out of their way to say "I2C" without having to say it...I guess you're supposed to get the idea that it's I2C then go look elsewhere for documentation. I found that the Micronas 3507 and ST STA013 MP3 chips both had good descriptions of I2C operation, too... --Keith BraffordArticle: 40688
Synthesis tools will generally not infer a carry chain unless it is expressed as an add, subtract, increment or decrement. Unless you can reduce your function to one of these, then you'll probably have to resort to instantiating the carry chain components. I'm not sure how much performance a carry chain parity will buy you, since it will require you to pull the carry out at each bit and feed it back into the di input of the muxcy (perhaps I missed something more elegant here). Kevin Brace wrote: > I will like to know if there is a way to infer a parity > generator that uses Virtex's carry-chains rather than LUTs? > The reason I am asking this question is because when I synthesize a > parity generator, XST uses LUTs rather than carry-chains even if "XOR > Collapsing" option is checked (enabled). > I will like to conserve valuable LUTs, and use carry-chains because > carry-chains are rarely used in my design. > Will I have to use Virtex specific primitives to do so, or is there a > way to do so without using Virtex specific primitives? > IF I have to use Virtex specific primitives, how do I do it? > Or is this problem XST's fault, and do other synthesis tools handle XOR > stuff differently than XST? > The parity generator here I am talking about is a one that generates the > parity of 36-inputs for PCI bus. > > Thanks, > > Kevin Brace (Don't respond to me directly, respond within the > newsgroup.)Article: 40689
'More or less' is the key phrase here. I have seen at least a half dozen different dialects of I2C over the years. michael brown wrote: > > One of the reasons that "two wire" interfaces that are nominally IIC > > are given a different name is that they aren't fully compatible with > > the spec, even though they interwork in every practical way. > > > > Regards, > > Allan. > > That may be partially true, but the primary reason that other manufacturers > don't call their parts IIC compatible is that Philips would make them pay > royalties to do so. Pretty much whenever you hear about two-wire > interfaces, it's probably IIC compatible (more or less). > > michael brownArticle: 40690
Hi, How would I know somebody has copied my files in Unix? -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sgArticle: 40691
>I have seen at least a half dozen different dialects of I2C over the years. Can there really be that many (6) variations? ;-) The protocol is pretty simplistic for a proprietary protocol. I can understand others not implementing some of the more esoteric features, but don't see allot of room for much variation in the scheme. Now, the Dallas 1-wire, there's a bitch of a protocol. ;-D I don't see too many variations of that floating around. Most people don't have a clue on how to interrogate the bus and deal with multiple devices dynamically (not that the datasheets make it crystal clear). If it wasn't for the skip-rom command, nobody would use 1-wire parts. ;-D No wonder though, it's a real PITA and there's really only one way to do it (AFAIK) michael brownArticle: 40692
Okay, if synthesis tools cannot infer a carry-chain parity generator
automatically, I guess I will have to use Virtex specific primitives.
I personally want synthesis tool vendors to give users an option to
select a carry-chain or LUT for implementing an XOR gate.
If I have to use Virtex specific primitives to build a parity
generator, should I use XORCY_L or XORCY_D?
Can I use XORCY_L only, and still be able to connect other carry-chains
located vertically without going out to the general routing resources?
Also, do I have to instantiate 35 or 36 of XORCY_L or XORCY_D to
complete the parity generator? (Trying to build a 36-bit parity
generator for PCI here.)
I guess using "generate" statement of VHDL might save time, but that is
not available in the current version of Verilog.
Thanks,
Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)
Ray Andraka wrote:
>
> Synthesis tools will generally not infer a carry chain unless it is
> expressed as an add, subtract, increment or decrement. Unless you can
> reduce your function to one of these, then you'll probably have to resort to
> instantiating the carry chain components. I'm not sure how much performance
> a carry chain parity will buy you, since it will require you to pull the
> carry out at each bit and feed it back into the di input of the muxcy
> (perhaps I missed something more elegant here).
>
Article: 40693Austin Lesea <austin.lesea@xilinx.com> writes: > Run an IBIS simulation. Is there any not-too-insanely-expensive software that can be used for this?Article: 40694
allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote in message news:<3c870132.9726435@netnews.agilent.com>... > On Wed, 06 Mar 2002 18:19:46 -0500, Greg Neff <gregeneff@yahoo.com> > wrote: > > >On Wed, 06 Mar 2002 21:08:39 GMT, John_H <johnhandwork@mail.com> > >wrote: > > > >I have not looked at the CEPT standard. We are using E1 physical > >layer stuff for a non-telecom application. Does the CEPT standard > >talk about mutual clock synchronization? If so, I would appreciate a > >pointer to this standard. I though that E1/T1 systems were typically > >clocked in a master/slave arrangement, or lived with slips. > > > > With regard to stability, I was thinking about the stability of the > >democratic clock, due to multiple feedback paths to the multiple phase > >error detectors on each PLL. > > > >>The references for stability... shouldn't they be contained in the > >>ITU-T specifications regarding E1 reference timing? The clock > >>distribution schemes, switchover conditions on signal loss, acceptable > >>jitter transfer and tolerance are all part of the CEPT standard. Very > >>constrained. > >(snip) > > As the other posters have mentioned, a "democratic" approach to timing > is unusual, and (to me) doesn't make sense. > > Regarding the ITU-T specifications, I think you should look at the > SONET/SDH specs instead of the E1 ones. > Try: ITU-T G.707 (SDH) and the G.810 series (SDH timing). > Also GR-253 (SONET). > > Even the Network Time Protocol (RFC1305) that is used to synchronise > time of day clocks on computers has a hierarchy of timing sources. > But it might give you some ideas that will help you with your problem. > http://www.ietf.org/rfc/rfc1305.txt > > Oh, you should probably look at the datasheets for chips that are > designed for phone network timing, e.g. Zarlink (nee Mitel) MT90401 > http://products.zarlink.com/partfinder/prodprofile.cgi?device=1127 > or maybe this one from Semtech: > http://www.semtech.com/products/sets.html > > Regards, > Allan. I have two questions related to the timing soloutions you have mentioned: 1)I've found a similar chip from Agere systems which is TSWC01622. But there is nothing more than a product brief on their website. http://www.agere.com/netcom/docs/PB00144.pdf I'll be grateful if someone provide me with more information (like a complete datasheet)about it. 2)According to MT90401 datasheet the two input references should have the same frequency. In my application I want to switch between two different clock rates so I can't feed both of them to the chip. After any failure of references MT90401 enters a holdover mode(suppose the failed clock frequency X). I WANNA KNOW if returning from holdover mode to a diffrent clock rate Y is safe and slip free. I know the manufacture can answer the question best but I thought you may know the structure of such devices. Best regards, MPArticle: 40695
Hi: I am programming with a Vertex board. I found that under JTAG mode I can only see the Spartan-II chip, but not the SST 39SF020A EEPROM, can anybody advice what has happened? Thanks. -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sgArticle: 40696
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:<qhvgc13z4q.fsf_-_@ruckus.brouhaha.com>... > Austin Lesea <austin.lesea@xilinx.com> writes: > > Run an IBIS simulation. > > Is there any not-too-insanely-expensive software that > can be used for this? Try Hyperlynx. It's inexpensive, relatively speaking. Bob Perlman ---------- Cambrian Design Works http://www.cambriandesign.comArticle: 40697
Hi , I have read in xilinx Answer Record #6713 that the recommend way is to asynchronously reset FFs in Virtex designs. Also says that reset signal will be routed in lines with minimal skews, is this process automatic or I must declare something in my code? Best Regards, Harris "Jay" <kayrock66@yahoo.com> wrote in message news:d049f91b.0203111736.2b606c03@posting.google.com... > In an ASIC, no, it shouldn't cause a problem, but in an FPGA where one > group of flops is being reset at time zero, and the other is being > reset 20nS later it could. The FPGA has special routing for the reset > net, if you put logic in there, you may be off into the general > purpose routing which is MUCH slower and higher skew. Since its > arbitrary, why don't you just make them the same (positive or > negative)? It's common to use a `define for the register always @(... > clause so you can change this stuff late in the game easily. > > Regards > > shengyu_shen@hotmail.com (ssy) wrote in message news:<f4a5f64f.0203062312.420d9e9@posting.google.com>... > > Hi everyone > > > > in my design, some module use high active reset, and other use low > > active reset, and the global reset is low active, so all high active > > reset is generate by pass global reset through an inverter, if this > > will cause any problem?Article: 40698
I think that with the toggling signals, they have a period of twice the clock period. It seems when using clk35x_p and clk35x_n, toggle35x_p and toggle35x_n can only resolve down to one clk35x resolution. The 90 degree phase shift sounds like one way to find a difference. I believe that I once saw an appnote that described using 90 deg phases to lock(?) onto an input signal. Now that you mention it, I do remember reading messages about clock skew and jitter in FPGAs. Also, several weeks ago, I looked into the Virtex-II skew/jitter when multiplying up the clock by 7x to the rate of 420 MHz. John_H wrote: > To avoid sampling the clock, you could do something a little different: > Have a toggle flip-flop clocked by clk10x. > Use the positive and negative edges of the clk35x to sample the toggle output. When > the sampled toggle value are different in the two time domains, you're at an edge of > the clk10x. Which edge of the clk35x you use to sample the difference determines > which edge you're on. > > In the past Ray Andraka's pointed out the troubles with using a DLL recovered clock > to sample signals in the reference clock's domain - clock skew and jitter can > sometimes make same-edge sampling unreliable. Depending on the allowable skew in > your data sampling, you might be able to add a small phase shift in the DCM on the > "safe" side. You might also figure out how to use the 90 degree version of the > clk10x to give you the timing margin you need but detect a specific middle timeslot. > > Mark wrote: > > > I did consider the approach you mentioned. I've been rather spoiled, having > > done nearly all synchronous designs. I don't have any real, meaning internal to > > FPGA chips, experience with "sampling" one clock with another.Article: 40699
Do you have any data how many gates it take to implement the pointer processor in FPGA ? Do you have data about this design ? Thanks
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