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
Thanks Allan, found an entry the verilog template provided with Xilinx ISE. But in that is instantiated as a primitive module. Is there any way we can instantiate it indirectly using verilog code.Article: 98701
> > Regarding creating a batch file from the GUI, you can just cut and paste
> > the
> > commands from the command_log file.
>
> Why should the (skilled) user have to trawl these log files ?
>
> It would be nice to configure via GUI, and then be able to
> run a created batch file, and get an indentical build.
No trawling for the command_log file needed. All you need to do is:
1) Run the process Design Utilities ->"View Command Line Log File"
this copies the latest command lines to the ISE Text Editor
2) Just File->Save As... mydesign.bat and you have your batch file
3) Open a command prompt and run the bat file
Article: 98702On 12 Mar 2006 09:34:04 -0800, "Peter Alfke" <alfke@sbcglobal.net> wrote: >In the early 'sixties, there was the "torsional delay line" memory: >A long (>20 m) piece of wire, rolled up and carefully suspended in a >box, with transducers at either end that kicked a twist into the wire >and sensed it at the other end. The wire materiel was such that the >temperature coefficient of the sound-wave propagation speed exactly >compensated the expansion of the wire length. >We (Sweda Cash Registers in Sweden) tried to put all the memory for a >whole cash register in there (15000 bits). It is amazing how creative >one can get when storage is that scarce... >But we eventually gave up. (And I moved to the US in '66...) >Peter Alfke >====================== > huh....I'd forgotten about that technique Peter. I never knew it had been used for digital-data storage; but the device you're describing sounds virtually identical to a regular old "reverb tank" as used in older guitar amps! ....and I'll bet you could use one of those tanks as-is, umodified, for data storage. Not sure what the BW of the end-transducers is; but it's got to be in the khz range. So many nutty things to play with....so little time....sigh.... :) ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 98703
On 13 Mar 2006 11:04:49 -0800, fpga_toys@yahoo.com wrote: Excellent post....thanks very much. I get SO tired of seeing answers which don't even address the question that was asked; and instead give the sadly-typical "oh, you can't do that yourself...". I've done qfp's, but never had a need to do BGA's; but am now expecting it to come up soon; so I appreciate you taking the time to give that detailed process-description. > >Contrary to others experience, I've done BGA parts pretty successfully >in "hobby mode", as well as with professional rework equipment. I've >developed a few "tricks" that help. > >First, solder paste is very difficult to manage with hand placement. >Instead, use water soluable flux on the board pads, and push a large >solder ball over all the boards pads till you have a small shinny >solder mound on each pad with a fairly uniform size to attach the BGA >with. Clean the board well to remove the used flux, and apply fresh >flux to both the board and the BGA balls. > >Second, position the BGA part on top of the pcb pads. It's very useful >at this point to have a silk screened outline of the package to center >the part with, that is very close to the real package size. > >Third, carefully place in a preheated convection oven, and bake. The >correct time for this takes some practice and calibration of YOUR >setup. Visually verify that the balls have a uniform "squat" on all >four sides ... this generally means the parts wetted fine, and the part >settled down on the balls at reflow temp. > >Read the lit about recommended profiles for various packages ... you >may not be able to exactly do those profiles, but you can come close >with some practice. > >I've had pretty good luck using several different table top forced air >"convection ovens" with digital controls. These are fairly inexpensive, >and typically can regulate temps within 10 degrees F or so. Their >problem, is uneven air flow which may result in uneven board heating if >you do not give this some thought. Two of the ovens I used, required >setting the board on a soda can near the center of the oven, with the >turn table removed. A third oven required fashioning a foil air duct to >make sure the hot air flow evenly covered the board. > >I suggest getting a non-contact IR thermometer with a spot capability >... these can be had fairly cheaply from a number of discount sources, >including Harbor frieght. Using a salvage pcb of similar size and mass >as your "test board" you can experiment with your "profile". I would >suggest starting with the oven preheated to about 10-25F higher than >your expected solder temp, quickly inserting your test board, and >letting it bake for 2-3 minutes, open the door and quickly read several >spots on the test board with the IR thermometer before the cool air >drops the temp too much. Let the test board cool back to room temp, and >repeat several times increasing the bake time about a minute each time. > When you find the point where the board just reaches the solder temp, >you can then program the oven to turn off 2 min after reaching that >temp, and slowly cool the board back down without thermal shocking the >BGA. > >Another process, is to pickup some slavage BGA parts with a similar >package, and make a test board with the on die thermal diode brought >out to test points, so you can run the wires out the door and monitor >the die temp as you develop your thermal profile. You can also do this >with your own board and FPGA's. You can also epoxy attach several >thermal diodes to a test board, and monitor the profile in real time at >several points. > >Pickup some Solderquik reballing preforms for the parts you plan to >use. That way you can clean off your mistakes, and reball the parts to >try again. > >The one thing you do not want to do, is get the newer BGA's too hot, or >thermal shock them with cold air. Older parts in BG432 and BG560 >packages are much more forgiving. I would suggest learning this >process with XC4K, Virtex, or Virtex-E parts in BG432/BG560 packages, >and once mastered move on to newer high density packages. ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 98704
Does anyone know of freeware spread-spectrum cores; particularly DS ? I'm looking for something which basically takes serial-data in and drives a GMK modulator at the output. Small, configurable, and with a simple DS scheme that doesn't have stringent acquisition needs. Issues are cost (complexity) and power; not security or speed (1mb/sec is fine). ps; any suggestion of 'standard parts' would be appreciated as well... thanks much ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 98705
jeverett@xilinx.com wrote: >>>Regarding creating a batch file from the GUI, you can just cut and paste >>>the >>>commands from the command_log file. >> >>Why should the (skilled) user have to trawl these log files ? >> >>It would be nice to configure via GUI, and then be able to >>run a created batch file, and get an indentical build. > > > > No trawling for the command_log file needed. All you need to do is: > > 1) Run the process Design Utilities ->"View Command Line Log File" > this copies the latest command lines to the ISE Text Editor > > 2) Just File->Save As... mydesign.bat and you have your batch file > > 3) Open a command prompt and run the bat file Sounds tolerable - does that give an identical build ? Is there any way to init the GUI, from such a log, should you wish to change one setting in 6 months time ? -jgArticle: 98706
I've checked the FpgaC version of AES encryption into the FpgaC sf.net
subversion archive under examples/crypto/aes with the Sbox macro
stubbed out waiting for the code Tom suggested. If someone plays with
it, and does the code replacement for the sbox arrays please send me
the changes and i'll include in the example for the next beta release
in April with your name attached.
svn co https://svn.sourceforge.net/svnroot/fpgac/trunk/fpgac fpgac
I got a start on updating FpgaC to handle platform specific technology
mapping so it can use F5/F6/F7 MUXes and do a better job of flattening
the combinatorial tree. Should probably have a chance to finish that
over the weekend, and get it checked in sometime next week. From
looking at the netlists, I suspect that will produce fairly optimal
implementation when done.
Any other suggestions?
Have fun,
John
fpga_toys@yahoo.com wrote:
> I did take the Deamon example code for study this morning, and while
> not suitable for FPGA implementation because of the all the serialized
> looping it was enough to understand the core algorithm pretty quickly.
> I re-wrote it into a fully unrolled subset C for FpgaC in a couple
> hours that is highly parallel, and pipelined at each round. The Sbox's
> are just stubbed out with a define macro, waiting for something
> reasonable to place in the macro. It appears that it should run at a
> pretty fair clip once someone can provide a set of C statements for the
> Sbox implementation you have reference.
>
> it does suffer a bit from a long standing problem we inherited from
> TMCC, which is that it doesn't know how to map F5/F6 muxes for
> extending 4-LUT equations, and tends to push terms down a little too
> quickly forcing a slightly deeper logic tree than optimal. This is also
> impacting the PCI core I started as demo code a few weeks ago.
>
> So, I'm off re-writting the FpgaC bottom end code to solve that
> problem for good. After the mux fixes, it appears FpgaC can compile the
> AES engine to netlist very well, along with the earlier RSA demo code's
> barrel shifters.
Article: 98707Hi all I am new to vhdl and xilinx ise. I can generate the waveform for the code (no syntax error) but it produces an error whenever i try to run xpower from the project navigator. arch xxx of xxx ... variable test; ... for i in 0 to test-1 loop -- error generated states tat variable cannot be used for range ... end arch; however no error occurs if i do it the following method: arch xxx of xx for test in 0 to 10 loop ... for i in 0 to test loop ... end loop; end loop; end arch; the question is if i do not use variable for the 1st mtd; hw else can i do to get rid of that error. Is there a data type which i can use to make it work? or is there something which i overlooked? tks for any help ywzArticle: 98708
On 14 Mar 2006 21:57:38 -0800, fpga_toys@yahoo.com wrote: >I've checked the FpgaC version of AES encryption into the FpgaC sf.net >subversion archive under examples/crypto/aes with the Sbox macro >stubbed out waiting for the code Tom suggested. If someone plays with >it, and does the code replacement for the sbox arrays please send me >the changes and i'll include in the example for the next beta release >in April with your name attached. > > svn co https://svn.sourceforge.net/svnroot/fpgac/trunk/fpgac fpgac > >I got a start on updating FpgaC to handle platform specific technology >mapping so it can use F5/F6/F7 MUXes and do a better job of flattening >the combinatorial tree. Should probably have a chance to finish that >over the weekend, and get it checked in sometime next week. From >looking at the netlists, I suspect that will produce fairly optimal >implementation when done. > >Any other suggestions? How about inferring BRAM for the sboxes? That's what many implementations do. (I'm assuming the point of the exercise is to compare the results of an implementation written in C with one written in a more conventional HDL.) Regards, Allan >Have fun, >John > > >fpga_toys@yahoo.com wrote: >> I did take the Deamon example code for study this morning, and while >> not suitable for FPGA implementation because of the all the serialized >> looping it was enough to understand the core algorithm pretty quickly. >> I re-wrote it into a fully unrolled subset C for FpgaC in a couple >> hours that is highly parallel, and pipelined at each round. The Sbox's >> are just stubbed out with a define macro, waiting for something >> reasonable to place in the macro. It appears that it should run at a >> pretty fair clip once someone can provide a set of C statements for the >> Sbox implementation you have reference. >> >> it does suffer a bit from a long standing problem we inherited from >> TMCC, which is that it doesn't know how to map F5/F6 muxes for >> extending 4-LUT equations, and tends to push terms down a little too >> quickly forcing a slightly deeper logic tree than optimal. This is also >> impacting the PCI core I started as demo code a few weeks ago. >> >> So, I'm off re-writting the FpgaC bottom end code to solve that >> problem for good. After the mux fixes, it appears FpgaC can compile the >> AES engine to netlist very well, along with the earlier RSA demo code's >> barrel shifters.Article: 98709
On 14 Mar 2006 19:22:15 -0800, "vssumesh" <vssumesh_asic@yahoo.com> wrote: >Thanks Allan, found an entry the verilog template provided with Xilinx >ISE. But in that is instantiated as a primitive module. Is there any >way we can instantiate it indirectly using verilog code. Various RAMs can be instantiated or inferred from your source code. You should read the XST manual - it will show you how. Regards, AllanArticle: 98710
Allan Herriman wrote: > How about inferring BRAM for the sboxes? That's what many > implementations do. (I'm assuming the point of the exercise is to > compare the results of an implementation written in C with one written > in a more conventional HDL.) May seem strange, but the point wasn't to do a head to head comparison with other HDL's. I've some interest in crypto algorithms and have been on a search for "projects" which I can use as examples for the FpgaC release. The changes for technology mapping F5/F6 muxes has been on my list since last summer. AES and PCI examples just drove the point home it should be now, not later. The AES algorithm was easy to unroll by hand once I had an idea of what the core computation was ... the whole project took a little less than two hours start to finish. About an hour to code and debug the define macros for the first round (embedding row shift order), and another hour to cut, paste, and hand edit it as fully unrolled and finish setup of the test bench. I'm a very experienced C coder, so it might take someone else a bit longer. I also visualized the parallelism needed early in the project, and coded to obtain/maintain it.Article: 98711
Allan Herriman schrieb: > Hi Eilert, > > That's the idea. Your numbers are a little out though. Using a > mature FPGA process (with moderate speed grade) is likley to result in > a clock of about 200MHz if hand placement of the sboxes is used. > > AES takes 14 rounds per block. > It might be possible to have feedback around that block without > wasting another clock, but let's assume that it takes 1 extra clock > for the feedback mux, which gives 128 bits of result every 15 clocks. > This results in a throughput of 1.7Gb/s. > > A newer FPGA + fastest speed grade + hand placement of some LUTs might > double the numbers. I doubt it could reach a 500MHz clock in an FPGA. > > Of course, if one isn't using a feedback mode, many AES engines can be > run in parallel for a vast increase in speed. Alternately, the loops > can be unrolled for the same effect. > > I notice that OC192 / STM64 AES encryptors have been available for a > couple of years. I assume these have a single FPGA which produces > approx 20Gb/s of crypto material (10Gb/s encrypt, 10Gb/s decrypt + the > encrypt and decrypt streams are different so they can't share any > hardware). > > Regards, > Allan Hi Allan, yes, I used some extreme examples to show what's possible with stuff that is widely available (especially to students) like Spartan2/virtex. There you rarely get system clocks above 100MHz for larger designs. For the number of rounds I said "at least". That is 10 for the 128 bit key, 12(?) for the 192 bit key and 14 for the 256 bit key. Of course I chose the fastest option to get a higher result in the end. Adding 4 clocks for the feedback mux might have been a little overestimated when using a single mode. But in the end it was just an example. No need to make a fuss about some 100 Mbits :-) The 500 MHz,as mentioned, are just taken from the comercials. But I'm pretty sure it will be reachable with the Virtex 7 silicon (whenever that will be). Well, unrolling the loops was what I meant with "additional rounds and decrease the number of iterations". Sorry if I didn't said it right. For the Sonet encryptors you mentioned I found no information about the modes they use. Can it be possible that they use CTR-Mode? That one can use parallel engines indeed. All you need are modulo counters for each engine and feed them with incremental starting values. Also, for most modes including CTR you only need encryption rounds. I'm not sure if that helps any in sharing hardware, but at least you are working with only one kind of modules (e.g. only Sboxes and no invSboxes etc.) That eases the design of the chip a lot. Best regards EilertArticle: 98712
related topic http://www.fpgajournal.com/articles_2006/20060228_open.htmArticle: 98713
To John_H I am a beginer in this type of advanced concepts. I am also facing the same problem of multiple read port and multiple write port. But i could not understand the concept in your design. Please explain little bit more. Thanks in advance SumeshArticle: 98714
maxascent wrote: > I have a DDR design from Xilinx MIG and the lock signal never moves from > '0'. So I have just created my own design with just a DCM and the lock > signal still is '0'. I cant see that I am doing anything particularly > wrong? > > Cheers > > Jon Are you resetting the DCM (after at least 16 clocks) ? is your input clock at least 25 MHz? did you set the resolution of the simulator at 1ps? FrancescoArticle: 98715
Jake Janovetz wrote: > > I, too, prefer command line tools for many things. Unfortunately, when > I moved to Windows out of necessity (CAD software mainly), I realized > that the environment is just CL-hostile. That's why god invented Linux. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Perl as a language has less a design than a thousand special features flying in close formation." -- From the c2 wikiArticle: 98716
On Wed, 15 Mar 2006 08:53:26 +0100, backhus <nix@nirgends.xyz> wrote: >Allan Herriman schrieb: >> Hi Eilert, >> >> That's the idea. Your numbers are a little out though. Using a >> mature FPGA process (with moderate speed grade) is likley to result in >> a clock of about 200MHz if hand placement of the sboxes is used. >> >> AES takes 14 rounds per block. >> It might be possible to have feedback around that block without >> wasting another clock, but let's assume that it takes 1 extra clock >> for the feedback mux, which gives 128 bits of result every 15 clocks. >> This results in a throughput of 1.7Gb/s. >> >> A newer FPGA + fastest speed grade + hand placement of some LUTs might >> double the numbers. I doubt it could reach a 500MHz clock in an FPGA. >> >> Of course, if one isn't using a feedback mode, many AES engines can be >> run in parallel for a vast increase in speed. Alternately, the loops >> can be unrolled for the same effect. >> >> I notice that OC192 / STM64 AES encryptors have been available for a >> couple of years. I assume these have a single FPGA which produces >> approx 20Gb/s of crypto material (10Gb/s encrypt, 10Gb/s decrypt + the >> encrypt and decrypt streams are different so they can't share any >> hardware). >> >> Regards, >> Allan > >Hi Allan, >yes, I used some extreme examples to show what's possible with stuff >that is widely available (especially to students) like Spartan2/virtex. >There you rarely get system clocks above 100MHz for larger designs. > >For the number of rounds I said "at least". That is 10 for the 128 bit >key, 12(?) for the 192 bit key and 14 for the 256 bit key. Of course I >chose the fastest option to get a higher result in the end. Customers interested in these speeds seem to care about their data, and hardware that doesn't support a 256 key probably won't be commercially viable, so 14 clocks it is. Whether there's a practical difference in the security for key sizes of 128, 192 or 256 bits is another matter. >Adding 4 clocks for the feedback mux might have been a little >overestimated when using a single mode. But in the end it was just an >example. No need to make a fuss about some 100 Mbits :-) > >The 500 MHz,as mentioned, are just taken from the comercials. But I'm >pretty sure it will be reachable with the Virtex 7 silicon (whenever >that will be). > >Well, unrolling the loops was what I meant with "additional rounds and >decrease the number of iterations". Sorry if I didn't said it right. > > > >For the Sonet encryptors you mentioned I found no information about the >modes they use. Can it be possible that they use CTR-Mode? It's a pretty sure bet they're using CTR mode, since that is the only secure mode that doesn't use feedback. ECB doesn't use feedback, but isn't secure. The other modes use feedback. > That one can > use parallel engines indeed. All you need are modulo counters for each >engine and feed them with incremental starting values. Also, for most >modes including CTR you only need encryption rounds. I'm not sure if >that helps any in sharing hardware, but at least you are working with >only one kind of modules (e.g. only Sboxes and no invSboxes etc.) That >eases the design of the chip a lot. Regards, AllanArticle: 98717
For the subversion impaired :( http://svn.sourceforge.net/viewcvs.cgi/fpgac/trunk/fpgac/examples/crypto/aes/aes.c?view=markup&rev=49Article: 98718
You only need one fast clock at whatever freq you get near fmax, and use clock enables to move the datapath pipeline forward every 1/3 fast clock. The only thing I don't like about that is the energy needed to clock all the logic at 3x the enabled rate but it is safe. A more elaborate clock system could produce 3x and 1x with out skew too. Synthesis will then tell you your new limit is your datapath or control logic while your BRAMs have good slack. You must have some deep logic paths which is to be expected for an early design. Perhaps you can now think about using the 3x or full clock to redesign that 100MHz logic to get it to run a bit faster using less hardware and or more pipelines. Perhaps you have wide adders or muls, try pipelining these, other than that I can't say without knowing your architecture. I assume you can synth each block seperately to get a feel for what each block limit is. When you put them all together they will usually run slower. Remember, in FPGA, the BRAMs are about as good as in an ASIC but the logic is proportionately say 3x slower so optimal FPGA architecture can never be the same as for ASIC. The adders are worse since you are stuck with ripple designs while real ASIC designs can use alll sort of neat look ahead or carry save or carry select, but don't waste time in that direction in FPGA. So what is your widest adder or deepest logic path? JohnArticle: 98719
Hi there, I have not used DSP Builder, but have used System Generator, and also Synplify DSP, a similar tool from Synplicity. These are both able to integrate into Matlab and allow you to use the filter design tools it provides to design filters easily - only a couple of steps are needed to go from a filter specification in Matlab to a finished hardware design in most cases. As well as allowing you to target chips from both Altera and Xilinx, Synplify DSP also has a couple of extra interesting features. It allows you to automatically fold a system (ie. go from a fully parallel specification to one which uses shared functional components), or automatically multi-channelize it so that several interleaved channels of data are processed by the same hardware. Cheers, Jon lecroy7200@chek.com wrote: > I am evaluating them to see if they would be any benifit for a project > I am working on. So far I have not been able to run the Xilinx tool > because they do not support the current version of Mathworks. From > what I can tell it is possible that the whole design could be done in > Simulink using the Altera tools, but I find myself asking why. The > only real benifit I can see is that the Mathworks tools make a great > functional simulation tool. I guess I could see where the wiring could > be faster for some people. I am surprized that Altera does not have > all of the Simulink functions in the Mega libs. > > Has anyone used one of these tools? What's your thoughts?Article: 98720
There is a similar trick which used to be tought in CS for how to exchange 2 registers without using a temp reg. Since xor and mov usually both take 1 cycle but may not have same effect on CC flags. A <= A^B; B <= A^B; A <= A^B; gives the same result as T <= A; A <= B; B <=T; If you can get your head around that, then its the same idea on a bigger scale. Remember that the valid read value on any top level R port is the ^ of all 3 ports so any write to that same address must contribute bit toggles that cancel out twice leaving only the desired data. Assume the other 2 guys writing data are only writing 0s so in effect write port A always writes X^0^0 into ram A and the read is going to be X ^ 0 ^ 0 again. If the 2nd guy wrote Y to ram 2 before hand, then change a 0 for Y on both the write and read for X and it cancels out. Same again for 3rd guy writing Z to port 3. This can go on for more ports but requires NN Rams. John JaksonArticle: 98721
It turns out I did not have the feedback signal connected. So it all works fine now. Thanks JonArticle: 98722
metal wrote: > Does anyone know of freeware spread-spectrum cores; particularly DS ? > > I'm looking for something which basically takes serial-data in and > drives a GMK modulator at the output. Small, configurable, and with a > simple DS scheme that doesn't have stringent acquisition needs. > > Issues are cost (complexity) and power; not security or speed (1mb/sec > is fine). > > ps; any suggestion of 'standard parts' would be appreciated as > well... > > thanks much Yes, there is a spread spectrum clock generator : The LTC6902 5kHz to 20MHz multiphase capable. For 2.90$. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 98723
Jim Granville napisal(a): > IIRC there was an earlier thread on this, and I think the consensus > was to use one quarter of the MAX time. > [.. but the IC vendors really _should_ include this in the data sheets...] > -jg Thanks, I found this thread. The most pesimistic approach is: Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max) - 2xCLKOUT_PER_JITT0 - 2xCLKIN_CLKFB_PHASE. I only wonder why period jitter and phase error are doubled in this equation? WJArticle: 98724
vssumesh wrote:
> To John_H
> I am a beginer in this type of advanced concepts. I am also facing the
> same problem of multiple read port and multiple write port. But i could
> not understand the concept in your design. Please explain little bit
> more.
> Thanks in advance Sumesh
Repeating the response to a previous thread which included code:
> The RTL (Verilog or VHDL) can take care of instantiating the correct number
> of dual-port RAMs.
>
> if( WeA ) MemA[AddrA] <= MemB[AddrA]^MemC[AddrA]^DinA;
> if( WeB ) MemB[AddrB] <= MemA[AddrB]^MemC[AddrB]^DinB;
> if( WeC ) MemC[AddrC] <= MemA[AddrC]^MemB[AddrC]^DinC;
> ...
> assign RdA = MemA[AddrA]^MemB[AddrA]^MemC[AddrA];
> assign RdB = MemA[AddrB]^MemB[AddrB]^MemC[AddrB];
> assign RdC = MemA[AddrC]^MemB[AddrC]^MemC[AddrC];
> assign RdD = MemA[AddrD]^MemB[AddrD]^MemC[AddrD];
>
> In this configuration you have 3 read/write ports using the same address for
> either read or write and you have a 4th read-only memory. The counting of
> memories needed to implement your n-port memory is only for resource
> determination; your synthesizer will - in the example above - need 4
> memories to support RdB: a single port at MemB (which is shared with other
> dual ports) and two dual-ports with the other write addresses for the input
> and the read address for the output.
Each write port has its own memory associated with it. When you're
writing to one port since you can't update the others, you have to make
the data "right" independent of which write port was last used. The XOR
lets your latest input data store into your memory
MemA[AddrA] <= MemB[AddrA]^MemC[AddrA]^DinA
and retrieve the original data that was written
RdA = MemA[AddrA]^MemB[AddrA]^MemC[AddrA]
= (MemB[AddrA]^MemC[AddrA]^DinA) ^ MemB[AddrA]^MemC[AddrA]
= DinA^(MemB[AddrA]^MemC[AddrA]) ^ MemB[AddrA]^MemC[AddrA]
= DinA ^ (MemB[AddrA]^MemB[AddrA]) ^ (MemC[AddrA]^MemC[AddrA])
= DinA ^ 0 ^ 0
= DinA
You can't touch the other memories for writes but you can access them
for reads allowing you to retrieve the most recently written Din value
from the set of write ports.
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