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
Have a look at the document accessed from here: http://innovexpo.itee.uq.edu.au/2003/exhibits/s354025/ On page 96, the hardware for the TT800 RNG is described, which is essentially a smaller version of the mersenne twister. "Bevan Weiss" <kaizen__@NOSPAMhotmail.com> wrote in message news:aqE1c.1764$Nc3.27111@news.xtra.co.nz... > I'm trying to find some information on how the mersenne twister pseudo > random number generator would be implemented in hardware. So far the only > descriptions I can find for the algorithm relate to 32bit (or more) software > operations. > > If anyone has any information on how I might go about such an implementation > or any links on where I might be able to get more information on how to > perform such an implementation it would be greatly appreciated. > > Thanks, > Bevan Weiss > > >Article: 67076
The LUT content is defined in the bitstream. That defines the original state of the latch. Same for SRL16. Peter Alfke > From: rickman <spamgoeshere4@yahoo.com> > Reply-To: spamgoeshere4@yahoo.com > Newsgroups: comp.arch.fpga > Date: Thu, 04 Mar 2004 16:29:06 -0500 > Subject: Re: Global reset question? > > Peter Alfke wrote: >> >> rickman is right, GSR forces every flip-flop in the chip. Faced with the >> need to store some bits that must be unaffected, I have suggested using >> latches made up of feddback across one LUT, but nowadays the SRL16 would >> be better. You just shift in some data into the SRL16, and you can rest >> assured that it will remain undisturbed by GSR. > > Although that begs the question of how is this latch set on the initial > power up of the part? It will either power up randomly (differently) > each time, or it will power up in a consistent state, but not defined. > I guess whether this matters depends on how it is being used... > > -- > > 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: 67077
On Thu, 04 Mar 2004 09:24:37 -0700, Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote: > >Allan, > >We were having a little trouble with our server's posting ability so it >might not be your fault. The sad part is I have written several >responses to people over the past few months but no one could see them >unless you look at our server (it showed up on our server but not the >outside world so I thought they were getting out). I think all is fixed >now and if you are reading this, then hopefully the problem is corrected >and should not cause confusion going forward. Sorry about that. > >BTW, that attribute is in the 6.1i Constraints Guide on page 333 but >looks like you might have found it now. Hi Brian, Reading you loud and clear. I think I was misled by a statement on page 254 of the XST User Guide that said "You must use the KEEP constraint instead of SIGNAL_PRESERVE" (which is wrong), and didn't mention equivalent_register_removal at all. Regards, Allan.Article: 67078
"OP" <omnipresent@hotmail.com> wrote in message news:a0539759.0403031405.4f790e93@posting.google.com... > Hello, > I would like to the different Finite Field Multipliers used for doing > Finite Field Multiplication? Also specifically ones that do in > Polynomial Basis?? > and for FPGA Implementation too!!!! > any help regards to references to these design of multipliers and if > possible a reference to the comparison of different multipliers would > greatly appreciated. > Thanx. OP. This is a similar tone of question to the one you posted on the 25th February... Hi, Feeling really intelligent today.. I would like to know some basic stuff.. What is the difference between a hardware implementation of an algorithm and a software one. How do you say an algorithm is faster in one and slower in other.. if it's based on timing how do you do that?? What makes it faster in one and not in other?? all the help is appreciated. ....do you have another assignment due? Nial.Article: 67079
The configuration holds the LUTs contents which defines the combinatorial
function of the LUT, but that does not describe the LUT's output value. You
cross couple two luts, but I don't see how you force a particular initial value
from initialization. This is much different than an SRL16, where the
configuration bits are the SRL16 state, or even a flip-flop where the state is
part of the initialization. What am I missing here?
Peter Alfke wrote:
> The LUT content is defined in the bitstream. That defines the original state
> of the latch. Same for SRL16.
> Peter Alfke
>
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 67080rickman <spamgoeshere4@yahoo.com> wrote in message news:<40476B76.3E2C7BC8@yahoo.com>... > I want to find a way to connect this programming interface directly to > the CPU as if it were a peripheral device. So far I have not figured > out a way to do that. > > Most CPUs provide a WR- signal that changes *within* the CS- being > active. So that would trigger an abort if connected directly. Further, > there is no signal equivalent to the CCLK coming from an MCU. Oh, an asynchronous bus interface. Yeah, that would be a bit more difficult. > But I can say I have finally figured out the documentation on the bit > stream format. Maybe it is just me, but I find the Xilinx documentation > on configuration is very cryptic. I had to read and reread that section > over a dozen times to finally understand all the difficult parts. The only funny stuff I've run across is documented in App502. Bit ordering on the D0..D7 bus (taken care of on-board -- who calls D0 MSB???) and the search for the 0xFF start codes in the .bit file. Though, admittedly, I haven't done partial reconfig. > I also want to have my FPGA design be able to use this same interface, > but not give up partial reconfiguration. At this point I am pretty sure > the only way to map my FPGA design to the CPU bus and still retain the > ability for partial reconfiguration is to have *two* separate interfaces > on the FPGA. So I will have to have two sets of data bus pins and two > sets of WR-, CS-, etc on the FPGA. Yeah, there doesn't appear to be a 'selectMAP select' pin, eh? JakeArticle: 67081
On 04 Mar 2004 22:48:21 +0100, Petter Gustad wrote: >I hardly ever use Windows so I haven't had a chance to observe this. I >don't have a HT system at hand now, but what does > >grep ^processor /proc/cpuinfo > >return on a Linux based HT system? Sorry, don't know from personal experience. I don't use Linux much, and when I do, I run it under VMware, which emulates a uniprocessor. I've heard from other users that Linux understands HT, but I don't know any more than that, really. I daresay the folks in some of the hardware groups could say more - try alt.comp.periphs.mainboard.supermicro -- MaxArticle: 67082
On Thu, 4 Mar 2004 17:34:25 +0000 (UTC), Max wrote: >I wouldn't want to try to convert it to use less than 32-bit >operations though, since you're inevitably going to lose a great deal >of the performance that presumably caused you to choose it in the >first place. What would be the period of a 16-bit implementation, for >instance? D'oh! Brain fade :o(( MT essentially operates on a single 19937-bit number, so the period will remain the same irrespective of how that number is stored in hardware. Using other than 32-bit words would make the logic very awkward and slow to implement, however. What's the problem with using 32-bit wide registers, anyway? -- MaxArticle: 67083
"Max" <mtj2@btopenworld.com> wrote in message news:af0g401l1him14b1a9sadnq7n7229fk6p3@4ax.com... > On Thu, 4 Mar 2004 17:34:25 +0000 (UTC), Max wrote: > > >I wouldn't want to try to convert it to use less than 32-bit > >operations though, since you're inevitably going to lose a great deal > >of the performance that presumably caused you to choose it in the > >first place. What would be the period of a 16-bit implementation, for > >instance? > > D'oh! Brain fade :o(( > > MT essentially operates on a single 19937-bit number, so the period > will remain the same irrespective of how that number is stored in > hardware. Using other than 32-bit words would make the logic very > awkward and slow to implement, however. > > What's the problem with using 32-bit wide registers, anyway? > > -- > Max I'm after a PRBS so it just seems a bit awkward to go from a twisted generalised shift register (TGSFR) type algorithm (which the mersenne twister is based on) to a 32bit register type approach (as all the software processes use) only to have to go back to a shift register type arrangement at the output to get back into a serial stream. My desire would be for a feedback shift register type implementation (which is easily and efficiently done in an fpga or a cpld) It's for a type of cryptology application. I want to use the output to simply encrypt some bitstream, using a simple XOR gate. Decryption would then be exactly the same process, just XOR the encrypted stream with the same PRBS to get back the original data. I actually want to expand the operation so that it performs it on a single 19937bit shift register as opposed to many 32bit registers.Article: 67084
Hi Kenneth, > I started out looking for a 32bit Athlon vs. 64bit, but couldn't find any > exact matches on a GHz vs. GHz, but the slower 64bit cpu's trounced the 32 > bit XP's even given its faster clock. Looking through the SPEC results again, I think I may have misread them the first time I tried to mine through for this data. It's possible I compared 32-bit and 64-bit results on two machines that had different speed processors, which would have been pretty silly. Here's what I found this time: Under Spec CINT2000 results, you'll find 8 results listed as AMD "A4800". The third entry in the list appears to be a 1.8 Ghz Opteron 144 w/ 2GB RAM running SuSE 8 and is compiled using gcc targeting 64-bit instruction set (I believe that's what SPEC_CPU2000_LP64 means but am not positive). The fourth entry appears to be the same machine and OS except with code targeting 32-bit instructions. This is the only example of 32-bit vs. 64-bit I could find in this listing. Overall SPEC Results (higher better) 32-bit 1045 64-bit 980 (-6%) 175.VPR results (higher better) 32-bit 865 64-bit 957 (+10%) 300.Twolf results (another p&r tool): 32-bit 1133 64-bit 997 (-12%) So what do I think now? I think results on one computer on a couple tools can't tell us the whole story and that we need more data for a meaningful conclusion. But I'll stick to my original conclusion that 64-bit won't be a silver bullet for speed -- it may give a small boost or may not. Regards, PaulArticle: 67085
John Williams <jwilliams@itee.uq.edu.au> wrote in message c26isn$2lk$1@bunyip.cc.uq.edu.au... > > FSL (Fast Simplex Links) is even cheaper - and probably > much better suited to what you might have in mind. Yes, it is a good solutions in many cases, but it is not as generic as a shared bus could be... Regards, AntonioArticle: 67086
rickman wrote: > TRST puts the state machine in a defined state. Most devices also reset > the state machine on power up. In addition, if you hold the TMS line > high and clock TCK it will return the state machine to the starting > state after 5 clock cycles, IIRC. Of course, depending on the > implementation, the mechanism that operates the state machine can get > fouled up by power glitches or other anomalies. Then the machine may > get into a state that operating the TCK line may not control the state. > Then you will need a power on or a TRST type reset. I don't know that > this is common, but in theory it is possible. Thank you for the description. This is exactly that I also found. I do not use the TRST pin but I have never seen a case when the JTAG State Machine did not return to RESET state after 5 clocks. I use the JTAG chain for regular check of the FPGA input pins, not only for programming. The original question was the open TRST pin, but due to the standard internal pullup - I hope this is the case in Altera FPGAs too, but this was not yet confirmed by anybody - the open input must not be the reason for incorrect behavior. Janos EroArticle: 67087
Peter Alfke wrote: > I recently wrote a tutorial description of the Xilinx DCM features and > limitations. It's a bit long, but it might help some people in this newsgroup: > > Xilinx DCMs > This is a description of the capabilities and the limiatations of all > Xilinx Digital Clock Manager (DCM) circuits. > > Basic functionality: > In its simplest use, the DCM eliminates the clock delay between the > incoming clock signal and the low-skew global clock distribution. With > the appropriate feedback to its CLKFB input the DCM inserts the right > amount of delay so that CLKIN and CLKO signals occur simultaneously > (within a very small fraction of a nanosecond). Physically, CLKO is > delayed by exactly one clock period, and this obviously requires a > free-running, constant-frequency CLKIN. Isn't it CLKIN and CLKFB that occurs simultaniously? A typical example is if you use the DCM for of chip de-skewing. In this case you would like a certain point of the net on the PCB to be phase aligned with CLKIN. This requires that the CLK0 path to this point and the FB path from this point back to the DCM are matched. When the CLKFB and CLKIN are in phase this specific point will be phase aligned with CLKIN but not CLK0. > > In BASE mode the incoming clock frequency can be multiplied by any > integer from 1 to 32, or the clock frequency can be divided by any > integer from 2 to 16, as well as divided by the non-integer values of > 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, and 7.5. The output is edge-aligned with > the rising CLKIN edge whenever that is mathematically possible. (When > divided by x.5, only every other output edge is aligned with the input > edge). For integer multiply and divide ratios, the output is > automatically adjusted to a 50% duty cycle. > In BASE mode, the max frequency limit aplies to input and output > frequencies, but the min frequency limit of 24 MHz applies only to the > input frequency. > > In Frequency Synthesis mode,the incoming clock frequency can be > simultaneously multiplied and divided by any integer from 1 through 32. > A 200 MHz input, for example, can be multiplied by 19 and divided by 20 > to generate a 190 MHz output. Since multiplication and division are > performed mathematically, no 3.8 GHz internal frequency is generated. In > FS mode, the max frequency limit aplies to input and output > frequencyies, but the min frequency limit of 24 MHz applies only to the > output (!) frequency. > > Note the difference: > In BASE mode it's the input frequency that must be above 24 MHz, > in FS mode it's the output frequency. > > Practical examples in BASE mode: > 26 MHz : 13 = 2.0 MHz, > 250 MHz : 2.5 = 100 MHz, > 50 MHz x 5 = 250 MHz > > Practical examples in Frequency Synthesis mode: > 10 MHz x 31 : 5 = 62 MHz > 200 MHz x 27 : 20 = 270 MHz > > Not possible: > 20 MHz : 5 = 4 MHz > ( input frequency is too low for BASE mode, and output frequency is too > low for FS mode. Use flip-flop dividers instead) > > 7 MHz x 6 : 5 = 8.4 MHz > (output frequency is too low, change to > 7MHz x 24 : 5 = 33.6 MHz > and use two flip-flops to divide by the output by 4.) > > The flip-flops can then drive the global clock buffer, but do not > guarantee the tight delay specification offered by the DCM. Note however > that phase coherence in FS mode obviously can occur only once every D > input cycles = once every M output cycles, and usually is irrelevant in > a real application. > > Input Jitter: > The DCM is guaranteed to tolerate max 1 ns of cycle to cycle jitter on > its input. Higher jitter can cause the DCM to loose lock, which is then > indicated on the Lock output going High, or the CLKFX_Stopped bit going High. > > Output jitter: > Use the software tools to calculate the output jitter. There are > additional software tools available to evaluate the effect of M and D on > the output jitter. Contact your FAE.. > > Phase Shift Operation: > The DCM can provide phase-shifted outputs. > > In BASE mode, it provides the input frequency with four phase angles ( > 0, 90, 180, and 270 degrees), as well a the double frequency and the > double frequency inverted (180 degr) > > In Phase Shifted (PS) mode, all outputs are shifted by a common amount, > defined by an 8-bit control word N that specifies the phase shift of > N/256 times the incoming clock period. The granularity is also limited > by the delay chain increments, roughly 30 ps. This determines the > effective resolution for frequencies above 150 MHz. > The user can specify any one of 256 values, and the DCM will make the > closest possible approximation, within 30 ps. > The value N is usually set by configuration, but can also be adjusted > dynamically during operation. > > I hope this long posting is helpful. > Peter Alfke, Xilinx Applications Regards Patrik ErikssonArticle: 67088
On Fri, 5 Mar 2004 19:09:12 +1300, Bevan Weiss wrote: >I'm after a PRBS so it just seems a bit awkward to go from a twisted >generalised shift register (TGSFR) type algorithm (which the mersenne >twister is based on) to a 32bit register type approach (as all the software >processes use) only to have to go back to a shift register type arrangement >at the output to get back into a serial stream. > >My desire would be for a feedback shift register type implementation (which >is easily and efficiently done in an fpga or a cpld) The problem there is that the MT is specifically designed to be efficiently implemented in software on a 32-bit CPU (as is it's little brother, TT800). This gives the general idea: http://choices.cs.uiuc.edu/~akapadia/project2/node10.html >It's for a type of cryptology application. I want to use the output to >simply encrypt some bitstream, using a simple XOR gate. Decryption would >then be exactly the same process, just XOR the encrypted stream with the >same PRBS to get back the original data. Ouch! MT is definitely not suitable for cryptographic use as it stands, and the sort of system you propose would be straightforward to break with differential cryptanalysis. It's intended for Monte-Carlo simulations only. The MT inventor's page I linked before highlights this (near the top of the page): http://www.math.keio.ac.jp/~matumoto/emt.html You could run the output from the MT through a trapdoor hash such as MD5 to secure the cyphertext, but there would still be potentially crucial weaknesses in key exchange, if you're not very careful. Why not use an existing cryptosystem which is known to be secure? There's a variety to choose from, and many are designed to be easy to implement in hardware. How about triple-DES, for example? Or even straight DES (with CBC) if your security needs are not quite so stringent? Rolling your own cryptosystem is rarely a good idea, unless you're a specialist in the field - and even they can get it wrong. For a general discussion of this, Phil Zimmerman's background documentation for PGP is worth reading. He once made exacly the same mistake you did ;o) -- MaxArticle: 67089
"Max" <mtj2@btopenworld.com> wrote in message news:3eeg4057v3c12078lt0dgpnfenfbs1mn1v@4ax.com... > On Fri, 5 Mar 2004 19:09:12 +1300, Bevan Weiss wrote: > > >I'm after a PRBS so it just seems a bit awkward to go from a twisted > >generalised shift register (TGSFR) type algorithm (which the mersenne > >twister is based on) to a 32bit register type approach (as all the software > >processes use) only to have to go back to a shift register type arrangement > >at the output to get back into a serial stream. > > > >My desire would be for a feedback shift register type implementation (which > >is easily and efficiently done in an fpga or a cpld) > > The problem there is that the MT is specifically designed to be > efficiently implemented in software on a 32-bit CPU (as is it's little > brother, TT800). This gives the general idea: > http://choices.cs.uiuc.edu/~akapadia/project2/node10.html > > >It's for a type of cryptology application. I want to use the output to > >simply encrypt some bitstream, using a simple XOR gate. Decryption would > >then be exactly the same process, just XOR the encrypted stream with the > >same PRBS to get back the original data. > > Ouch! MT is definitely not suitable for cryptographic use as it > stands, and the sort of system you propose would be straightforward to > break with differential cryptanalysis. It's intended for Monte-Carlo > simulations only. > > The MT inventor's page I linked before highlights this (near the top > of the page): > http://www.math.keio.ac.jp/~matumoto/emt.html > You could run the output from the MT through a trapdoor hash such as > MD5 to secure the cyphertext, but there would still be potentially > crucial weaknesses in key exchange, if you're not very careful. > > Why not use an existing cryptosystem which is known to be secure? > There's a variety to choose from, and many are designed to be easy to > implement in hardware. How about triple-DES, for example? Or even > straight DES (with CBC) if your security needs are not quite so > stringent? > > Rolling your own cryptosystem is rarely a good idea, unless you're a > specialist in the field - and even they can get it wrong. For a > general discussion of this, Phil Zimmerman's background documentation > for PGP is worth reading. He once made exacly the same mistake you did > ;o) > > -- > Max sorry I kind of simplified a bit... I wasn't just going to use the output from the mersenne twister algorithm to feed into the XOR. The output was going to be buffered and gated by another PRBS. A little more involved to explain... Essentially take two bits of the gating PRBS then for each different half nibble perform a particular gating operation on the mersenne twister output: ie 00 - ignore output of mersenne twister completely 01 - place mersenne twister output into buffer 10 - place inverted version of mersenne twister output into buffer 11 - ignore output of mersenne twister completely The gating PRBS would also be a mersenne prime GFSR, although one with reduced periodicity to that of the mersenne twister. I also read some information about such algorithms as blum blub shub. But again couldn't find any kind of hardware based implementations (ie designed for a fpga or cpld). I was really just looking for something slightly removed from mainstream... Just like a bit of challenge I guess. I'll have a look at the common algorithms too, I think they be sufficient for the requirements also. Thanks :)Article: 67090
Hi all, Does anybody know what are basic techniques to achieve a throughput of 4 bits per clock in FPGA for a viterbi decoder. Basically, what I want is the following: (1.) If I clock Viterbi decoder at clock frequency of 50 MHz to implement in FPGA/ASIC, what basic algorithm should I choose to achieve 200 Mbps throughput that means computing 4 decoding bits per clock. Any thoughts on this will be appreciated. Thanks and Regards NitinArticle: 67091
Hi, there: I am trying to create some RPM files. It is a 32-bit bus macro from scratch. ISE6.0.3i won't route any of the wires! Can anybody teach me where I am wrong? Best Regards, Kelvin Script: xst -ifn bm32.xst -ofn bm32.syr ngdbuild -p xc2v500-fg256-6 -uc bm32.ucf bm32.ngc map -u -pr b bm32.ngd -o bm32_map.ncd bm32.pcf par -w bm32_map.ncd bm32.ncd bm32.pcf # Run FPGA Editor to save it as nmc # save -w macro bm32_v2.nmc XST File: set -tmpdir . set -xsthdpdir ./xst run -ifn bm32.prj -ifmt mixed -ofn bm32 -ofmt NGC -p xc2v500-fg256-6 -top bm32 -opt_mode Speed -keep_hierarchy YES -hierarchy_separator / -bus_delimiter () -glob_opt AllClockNets -iobuf NO PRJ File: verilog work ./bm32.v Source codes: `timescale 1ns/1ps module bm32 ( LI, LT, RI, RT, O ); input [31:0] LI; input [31:0] LT; input [31:0] RI; input [31:0] RT; output [31:0] O; bm_4b_v2 bm_7 ( .LI( LI[31:28] ), .LT( LT[31:28] ), .RI( RI[31:28] ), .RT( RT[31:28] ), .O( O[31:28] ) ); bm_4b_v2 bm_6 ( .LI( LI[27:24] ), .LT( LT[27:24] ), .RI( RI[27:24] ), .RT( RT[27:24] ), .O( O[27:24] ) ); bm_4b_v2 bm_5 ( .LI( LI[23:20] ), .LT( LT[23:20] ), .RI( RI[23:20] ), .RT( RT[23:20] ), .O( O[23:20] ) ); bm_4b_v2 bm_4 ( .LI( LI[19:16] ), .LT( LT[19:16] ), .RI( RI[19:16] ), .RT( RT[19:16] ), .O( O[19:16] ) ); bm_4b_v2 bm_3 ( .LI( LI[15:12] ), .LT( LT[15:12] ), .RI( RI[15:12] ), .RT( RT[15:12] ), .O( O[15:12] ) ); bm_4b_v2 bm_2 ( .LI( LI[11:8 ] ), .LT( LT[11:8 ] ), .RI( RI[11:8 ] ), .RT( RT[11:8 ] ), .O( O[11:8 ] ) ); bm_4b_v2 bm_1 ( .LI( LI[ 7:4 ] ), .LT( LT[ 7:4 ] ), .RI( RI[ 7:4 ] ), .RT( RT[ 7:4 ] ), .O( O[ 7:4 ] ) ); bm_4b_v2 bm_0 ( .LI( LI[ 3:0 ] ), .LT( LT[ 3:0 ] ), .RI( RI[ 3:0 ] ), .RT( RT[ 3:0 ] ), .O( O[ 3:0 ] ) ); endmodule `timescale 1ns / 1ps module bm_4b_v2( LI, LT, RI, RT, O ); input [3:0] LI; input [3:0] LT; input [3:0] RI; input [3:0] RT; output [3:0] O; //..synthesis translate_off BUFT bm_buf3_l ( .O( O[3] ), .I( LI[3] ), .T( LT[3] ) ); BUFT bm_buf2_l ( .O( O[2] ), .I( LI[2] ), .T( LT[2] ) ); BUFT bm_buf1_l ( .O( O[1] ), .I( LI[1] ), .T( LT[1] ) ); BUFT bm_buf0_l ( .O( O[0] ), .I( LI[0] ), .T( LT[0] ) ); BUFT bm_buf3_r ( .O( O[3] ), .I( RI[3] ), .T( RT[3] ) ); BUFT bm_buf2_r ( .O( O[2] ), .I( RI[2] ), .T( RT[2] ) ); BUFT bm_buf1_r ( .O( O[1] ), .I( RI[1] ), .T( RT[1] ) ); BUFT bm_buf0_r ( .O( O[0] ), .I( RI[0] ), .T( RT[0] ) ); //..synthesis translate_on endmodule UCF file... INST "bm_7/bm_buf3_l" LOC = "TBUF_X22Y11"; INST "bm_7/bm_buf2_l" LOC = "TBUF_X22Y10"; INST "bm_7/bm_buf1_l" LOC = "TBUF_X20Y11"; INST "bm_7/bm_buf0_l" LOC = "TBUF_X20Y10"; INST "bm_7/bm_buf3_r" LOC = "TBUF_X26Y11"; INST "bm_7/bm_buf2_r" LOC = "TBUF_X26Y10"; INST "bm_7/bm_buf1_r" LOC = "TBUF_X24Y11"; INST "bm_7/bm_buf0_r" LOC = "TBUF_X24Y10"; INST "bm_6/bm_buf3_l" LOC = "TBUF_X22Y13"; INST "bm_6/bm_buf2_l" LOC = "TBUF_X22Y12"; INST "bm_6/bm_buf1_l" LOC = "TBUF_X20Y13"; INST "bm_6/bm_buf0_l" LOC = "TBUF_X20Y12"; INST "bm_6/bm_buf3_r" LOC = "TBUF_X26Y13"; INST "bm_6/bm_buf2_r" LOC = "TBUF_X26Y12"; INST "bm_6/bm_buf1_r" LOC = "TBUF_X24Y13"; INST "bm_6/bm_buf0_r" LOC = "TBUF_X24Y12"; INST "bm_5/bm_buf3_l" LOC = "TBUF_X22Y15"; INST "bm_5/bm_buf2_l" LOC = "TBUF_X22Y14"; INST "bm_5/bm_buf1_l" LOC = "TBUF_X20Y15"; INST "bm_5/bm_buf0_l" LOC = "TBUF_X20Y14"; INST "bm_5/bm_buf3_r" LOC = "TBUF_X26Y15"; INST "bm_5/bm_buf2_r" LOC = "TBUF_X26Y14"; INST "bm_5/bm_buf1_r" LOC = "TBUF_X24Y15"; INST "bm_5/bm_buf0_r" LOC = "TBUF_X24Y14"; INST "bm_4/bm_buf3_l" LOC = "TBUF_X22Y17"; INST "bm_4/bm_buf2_l" LOC = "TBUF_X22Y16"; INST "bm_4/bm_buf1_l" LOC = "TBUF_X20Y17"; INST "bm_4/bm_buf0_l" LOC = "TBUF_X20Y16"; INST "bm_4/bm_buf3_r" LOC = "TBUF_X26Y17"; INST "bm_4/bm_buf2_r" LOC = "TBUF_X26Y16"; INST "bm_4/bm_buf1_r" LOC = "TBUF_X24Y17"; INST "bm_4/bm_buf0_r" LOC = "TBUF_X24Y16"; INST "bm_3/bm_buf3_l" LOC = "TBUF_X22Y19"; INST "bm_3/bm_buf2_l" LOC = "TBUF_X22Y18"; INST "bm_3/bm_buf1_l" LOC = "TBUF_X20Y19"; INST "bm_3/bm_buf0_l" LOC = "TBUF_X20Y18"; INST "bm_3/bm_buf3_r" LOC = "TBUF_X26Y19"; INST "bm_3/bm_buf2_r" LOC = "TBUF_X26Y18"; INST "bm_3/bm_buf1_r" LOC = "TBUF_X24Y19"; INST "bm_3/bm_buf0_r" LOC = "TBUF_X24Y18"; INST "bm_2/bm_buf3_l" LOC = "TBUF_X22Y21"; INST "bm_2/bm_buf2_l" LOC = "TBUF_X22Y20"; INST "bm_2/bm_buf1_l" LOC = "TBUF_X20Y21"; INST "bm_2/bm_buf0_l" LOC = "TBUF_X20Y20"; INST "bm_2/bm_buf3_r" LOC = "TBUF_X26Y21"; INST "bm_2/bm_buf2_r" LOC = "TBUF_X26Y20"; INST "bm_2/bm_buf1_r" LOC = "TBUF_X24Y21"; INST "bm_2/bm_buf0_r" LOC = "TBUF_X24Y20"; INST "bm_1/bm_buf3_l" LOC = "TBUF_X22Y23"; INST "bm_1/bm_buf2_l" LOC = "TBUF_X22Y22"; INST "bm_1/bm_buf1_l" LOC = "TBUF_X20Y23"; INST "bm_1/bm_buf0_l" LOC = "TBUF_X20Y22"; INST "bm_1/bm_buf3_r" LOC = "TBUF_X26Y23"; INST "bm_1/bm_buf2_r" LOC = "TBUF_X26Y22"; INST "bm_1/bm_buf1_r" LOC = "TBUF_X24Y23"; INST "bm_1/bm_buf0_r" LOC = "TBUF_X24Y22"; INST "bm_0/bm_buf3_l" LOC = "TBUF_X22Y25"; INST "bm_0/bm_buf2_l" LOC = "TBUF_X22Y24"; INST "bm_0/bm_buf1_l" LOC = "TBUF_X20Y25"; INST "bm_0/bm_buf0_l" LOC = "TBUF_X20Y24"; INST "bm_0/bm_buf3_r" LOC = "TBUF_X26Y25"; INST "bm_0/bm_buf2_r" LOC = "TBUF_X26Y24"; INST "bm_0/bm_buf1_r" LOC = "TBUF_X24Y25"; INST "bm_0/bm_buf0_r" LOC = "TBUF_X24Y24";Article: 67092
Max <mtj2@btopenworld.com> writes: > On 04 Mar 2004 22:48:21 +0100, Petter Gustad wrote: > > >I hardly ever use Windows so I haven't had a chance to observe this. I > >don't have a HT system at hand now, but what does > > > >grep ^processor /proc/cpuinfo > > > >return on a Linux based HT system? > > Sorry, don't know from personal experience. I don't use Linux much, > and when I do, I run it under VMware, which emulates a uniprocessor. I got the answer from a local Linux group. It appears as 4 processors: $ grep ^processor /proc/cpuinfo processor : 0 processor : 1 processor : 2 processor : 3 So it will be difficult to distinglish between two physical CPU packages, dual-core and HT... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 67093
On Fri, 5 Mar 2004 23:01:01 +1300, Bevan Weiss wrote: >I was really just looking for something slightly removed from mainstream... >Just like a bit of challenge I guess. >I'll have a look at the common algorithms too, I think they be sufficient >for the requirements also. An interesting project might be to implement Rijndael/AES in an FPGA. It's pretty efficient for a block cypher algorithm, and about as secure as you can get: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ -- MaxArticle: 67094
Petter Gustad <newsmailcomp5@gustad.com> writes:
> So it will be difficult to distinglish between two physical CPU
> packages, dual-core and HT...
I think you can look at the "flags":
$ grep ^flags /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi
mmx fxsr sse sse2 ss ht tm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi
mmx fxsr sse sse2 ss ht tm
This is on a uni-processor Xeon box. The "ht" flag might hint at
hyperthreading, but I'm not sure...
Article: 67095Dear Dr VHDL I am a newbie struggling with an exercise to write a parameterised model of a PCB containg memory ICs. The answer (yes I peeked at the book but I wish I hadn't) contains this code fragment - subtype word is std_logic_vector(wordsize-1 downto 0) ; type mem is array(0 to 2**addresssize-1) of word ; variable memory: mem := (others=>word'(others=>'U')) ; Why does the above define a type from a subtype ? Is this cos VHDL doesn't allow subtypes of subtypes ? And more important - What does line 3 mean by (others=>word'(others=>'U')) ?. I understand stuff like (others=> 'U') but what sort of ?attribute of word is word'(others=>'U')) thanx John.Article: 67096
Yes, of course - I spent the entire 14 day return period doing nothing else. msm30@yahoo.com (William Wallace) wrote in message news:<7e4865b7.0403031802.49740a9b@posting.google.com>... > Did you verify that you had your port settings correct in the > laptop's BIOS? > > > eastwood132@yahoo.com (Ted Lechman) wrote in message news:<b89924f9.0403021447.48ec865d@posting.google.com>... > > I've discovered incompatability between the ModelSim dongle and > > certain notebook computer's printer ports: They are > > > > 1. Toshiba Satellite S150s (I would suspect all Satellites). I've > > experienced this personally. I had to returnthis notebook and get a > > CompaqPresario 2500 in its place to make sure the dongle works. > > 2. Sony notebooks ( my local distributor has had this problem). > > > > The rumor is that its a voltage incompatabilty issue, but I'm not > > sure. > > > > Ted Lechman > > Utica, NYArticle: 67097
On 05 Mar 2004 13:09:06 GMT, pears772@aol.com
(Pears772) wrote:
>Dear Dr VHDL
Yup, this one should have gone to comp.lang.vhdl.
>subtype word is std_logic_vector(wordsize-1 downto 0) ;
>type mem is array(0 to 2**addresssize-1) of word ;
>variable memory: mem := (others=>word'(others=>'U')) ;
>
>Why does the above define a type from a subtype ?
"type mem" is a completely new data type (an array of
a particular size of std_logic_vector) that has never
been seen before in this compilation; that's why it
needs the "type" keyword. By contrast, "subtype word"
is just a particular version of the existing type
std_logic_vector. Since it starts from the existing
definition of std_logic_vector and then constrains it
by specifying a specific subscript range, it's a subtype.
>Is this cos VHDL doesn't allow subtypes of subtypes ?
No, it's because you're defining something new.
In any case it's not strictly true that
"VHDL doesn't allow subtypes of subtypes"
because you can do this...
subtype SHORT is integer range -32768 to 32767;
subtype BYTE is SHORT range -128 to 127;
although you are partly right - you cannot make
a new subtype by further constraining the subscript
range on your subtype "word".
>And more important -
>
>What does line 3 mean by (others=>word'(others=>'U')) ?.
>I understand stuff like (others=> 'U') but what sort
>of ?attribute of word is word'(others=>'U'))
It's not an attribute. The syntax
typename'(expression)
is known as "type qualification" and it specifies that
the expression must be interpreted as being of the
specified type. It's useful if there is any ambiguity.
I am fairly sure that it's unnecessary in your example,
because the whole expression
(others => (others => 'U'))
is known to be of type "mem", so its elements are known
to be std_logic_vector(wordsize-1 downto 0), so there
is no ambiguity in the interpretation of (others=>'U').
However, a type qualification like this is ALWAYS
harmless, as it can't possibly change anything - the
expression must already be a legal value of the
specified type; no conversion takes place.
One very common use of type qualification is in
creating fixed messages to an output stream:
variable L: line;
file F: ....
...
write (L, string'("Title message"));
writeline(F, L);
The write() procedure is overloaded so that it can do...
write(L, string)
write(L, bit_vector)
Without the string'() type qualification, the VHDL
compiler would be confused because a bunch of characters
inside string quotes might also be a bit_vector.
(Yes, you and I know that a bit_vector can't have anything
other than 0 and 1 in it. But the compiler doesn't want
to make guesses about the string's contents.)
HTH
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 67098Kenneth Land <kland1@neuralog1.com1> wrote: > On Paul Leventis' info that the VPR Benchmark (Part of SPEC) is an FPGA > Place and Route program I went and looked at a few results at www.spec.org. > > The interface is hideous, but I managed to ferret out a few results: > > 2.0 GHz Opteron time 115, score 1215 > 2.0 GHz Athlon 64 time 127, score 1102 The difference here would be one of cache and memory system. > 2.2 GHz Athon XP (32bit) time 182, score 768 > 3.2 GHz Xeon (1MB cache) time 129, score 1085 > > > I started out looking for a 32bit Athlon vs. 64bit, but couldn't find any > exact matches on a GHz vs. GHz, but the slower 64bit cpu's trounced the 32 > bit XP's even given its faster clock. > > Interesting also that the super Xeon couldn't best the Opteron even with > over a GHz clock advantage. Forget clock rating - unless its the same processor, it doesn't really mean anything. > So if VPR is any indication then a 64 bit AMD system looks very promising. > > Ken > > -- Sander +++ Out of cheese error +++Article: 67099
Nicholas C. Weaver <nweaver@ribbit.cs.berkeley.edu> wrote: > > WILD A** guess says this probably comes down to the faster memory > heirarchy in the AMD 64 bit processors. Since the Athlon 64 has the > memory controller on the CPU, directly connecting to the DIMMs, memory > latency is something like 15 processor cycles + DRAM access, which is > amazingly low, saving 2 chip crossings and a boatload of chipset > overhead. It is not just that. The new AMD K8 core (used in AThlon 64 and Opterons) has a number of advantages over the old K7 core (used in Athlon XP, etc). you can read more on this on say www.chip-architect.com. -- Sander +++ Out of cheese error +++
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