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
In the design I have 256 3-bit registers, every time I need to read or write 16 of them (data_o0, 1, ...15). The read/write address is not totally random. For example, assuming that I arrange the register into a 16X16 matrix, data_o0 accesses among the zeros row or column. data_o1 may access from 20 of the registers, but not 256, data_o2 may access from 30 of the variables, etc. If I code such that every output reads from the 256 registers, the final logic will be overkill and highly redundant. If I use case statements to list each of the senarios, the RTL code may end up 500 kilobyte. Will design compiler synthesize a 500KB design efficiently? Will NCVerilog compile and simulate it efficiently? Are there any neater techniques to attack this problem?Article: 116401
On 2007-03-08, Daniel S. <digitalmastrmind_no_spam@hotmail.com> wrote: > All the GbE PHYs I have seen have their datasheets available only under NDA. Just one datapoint here: We are using an AVnet board with a National Semiconductor DP83861 10/100/1000 Ethernet PHY on it and the datasheet is available for download from their homepage. So there are PHYs with public documentation available. /AndreasArticle: 116402
Daniel, > VHDL 200X (which promises significant nonsense reduction) is getting > nowhere and it'd be years until ISE gets it right anyhow. VHDL-200X was transfered to Accellera VHDL TSC and has been standardized as their VHDL 3.0 standard. As such is a candidate for vendor implementation. If you like the features, let your vendor know as they are market driven and not driven by the existence of an updated standard. Cheers, JimArticle: 116403
Symon, Intel is keeping this secret. If true, it is a huge improvement, and one that the foundries will be itching to get their hands on. The hi-K dielectric for the transistor will keep the roadmap moving forward with lower leakage (the gates leak at 65nm and below), and perhaps better speed (hi-K makes the transistor stronger according to Intel). AustinArticle: 116404
Ulrich, Just go into any CMOS chip, and then immediately leave that chip. That is 35 ps right there (a 74AHC04 for example). If you use LVDS, and have perfect terminations, maybe it becomes 25 ps. Call it a limitation of the technology of bulk CMOS. If you do anything else, the number just gets bigger. If you anything wrong, the number also gets bigger (bad bypassing, bad SI, etc.) AustinArticle: 116405
On Mar 8, 10:06 am, Austin Lesea <aus...@xilinx.com> wrote: > Symon, > > Intel is keeping this secret. If true, it is a huge improvement, and > one that the foundries will be itching to get their hands on. > > The hi-K dielectric for the transistor will keep the roadmap moving > forward with lower leakage (the gates leak at 65nm and below), and > perhaps better speed (hi-K makes the transistor stronger according to > Intel). > > Austin I don't remember where I first saw it mentioned, but they are not keeping it a secret. Here are a few mentions about it: http://pubs.acs.org/cen/news/85/i06/8506notw4.html http://www.intel.com/technology/silicon/45nm_technology.htm And here is the leading supplier of it: http://www.wahchang.com/pages/products/data/hafnium.htm Regards, John McCaskill www.fastertechnology.comArticle: 116406
On Mar 7, 3:02 am, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1173237015.878201.302510@p10g2000cwp.googlegroups.com...> 1. Q <= (C and D) or (not(C) and Q); > > I have never seen such equation in my coding experiences and have no > > idea how this equation would be written. The logic result is beyond a > > reason. Could you please write it in equivalent latch equation in > > informal VHDL? > > It's the same old transparent latch that we've been talking about all along. > The following forms are exactly equivalent logic and will result in the > exact same synthesized result. > #1 -- Traditional form of writing a latch > process(C, D) > begin > if (C='1') then > Q <= D; > end if; > end process; > > #2 -- Another traditional form of writing a latch. > Q <= D when (C = '1'); > > #3 -- Latch equations written as a sum of products > Q <= (C and D) or (not(C) and Q); > > #4 -- Latch equation written in a sum of products form that includes a > 'cover' term > Q <= (C and D) or (not(C) and Q) or (D and Q); > > Try all four of the above out and run them through synthesis and you should > get the exact same fitted equations for all 4. > > Of the four different forms, only #4 is written in a way that will not have > timing issues that are caused simply by the implementation (over which you > have no real control in an FPGA). However, the last term ".. or (D and Q)" > is redundant and any synthesizer worth a dime will 'optomize the logic' and > implement it as form #3. This 'optomization' though creates a logic hazard > when 'C' switches from '1' to '0'. This logic hazard will in turn show up > as a failure in the latch operation. Specifically, what you'll run into is > that even if you have 'D' set up oodles of time before 'C' switches from '1' > to '0', the output 'Q' can latch itself at either '1' or '0' (depending on > the targetted part) because of differences in prop delay in computing the > first two or terms or glitches in 'C'. That last "D and Q" term is > absolutely required in order to even have a shot at inferring a latch that > will actually work but since it is logically 'redundant' it will always get > optomized away. If you hark back to Boolean Logic 101, you may recall that > adding redundant terms is the method you employ to get rid of logic hazards. > The FPGA LUT implementation leaves even more to the imagination as you > wonder just what those RAM outputs are doing with this combinatorial loop > and whether 'Q' will glitch and cause even more havoc since it would feed > back to the address input of the LUT. > > The bottom line is > - There are various forms of writing source code that infers a latch. > - Whether a latch is a 'good' thing or a 'bad' thing depends on the > targetted device itself and whether that device actually has a hard latch > and a way to guarantee the timing and glitch requirements of 'D' and 'C'. > - Inferring any storage element (flops, latches, memory) needs to be done in > such a way that the storage is not implemented as a collection of > LUTs/macrocells but instead uses hard storage resources of the device. > > > > > 2. FPGA of Xilinx chip really has latch primative and one may use it > > using latch primative to call it. But it is hard to refer to it in > > VHDL. > > You'll still have trouble meeting and guaranteeing the timing and glitch > requirements on 'D' relative to 'C' in order to get it to work correctly for > arbitrary signals 'D' and 'C'. If it does work, it likely won't scale well > (i.e. if you try to infer thousands of these as you would like to) > > > I don't mean VHDL should have included latch statement, what I > > mean is VHDL really lacks the statement element to refer to a latch in > > a clear and reliable way and the lack can be easily corrected. > > I've shown above four different forms for inferring the exact same latch > (i.e. synthesizes to the exact same thing). Which form you prefer (or if > you prefer to make up your own) to use is up to you. Making up a new method > though will not prohibit the earlier forms from being used and outlawing the > other forms gets in the way of people who do use latches and are doing so in > a way that they can control the various issues so you're not helping them by > outlawing their method. > > Kevin Jennings Hi KJ, I have another question for you. 1. Is any combinational equation with target signal in both right part and left part of the equation a latch like your equations 3 or 4 show? 2. Is there any general algorithm to change such an equation to a latch equation? Thank you. WengArticle: 116407
"John McCaskill" <junkmail@fastertechnology.com> wrote in message news:1173371757.756269.53650@h3g2000cwc.googlegroups.com... > On Mar 8, 10:06 am, Austin Lesea <aus...@xilinx.com> wrote: >> Symon, >> >> Intel is keeping this secret. If true, it is a huge improvement, and >> one that the foundries will be itching to get their hands on. >> >> The hi-K dielectric for the transistor will keep the roadmap moving >> forward with lower leakage (the gates leak at 65nm and below), and >> perhaps better speed (hi-K makes the transistor stronger according to >> Intel). >> >> Austin > > I don't remember where I first saw it mentioned, but they are not > keeping it a secret. Here are a few mentions about it: > > http://pubs.acs.org/cen/news/85/i06/8506notw4.html > http://www.intel.com/technology/silicon/45nm_technology.htm > > And here is the leading supplier of it: > > http://www.wahchang.com/pages/products/data/hafnium.htm > > Regards, > > John McCaskill > www.fastertechnology.com > I guess Austin means they're keeping the process details secret, not the results. Go to the above link you posted on intel.com and search for 'secret'! ;-) HTH, Syms.Article: 116408
Hi Dipu, dipumisc@hotmail.com writes: > I am using xilinx tools in an unix system to do the P&R and generate > the bit file. I am using a batch mode script to go through the steps. > Currently I am running impact in gui mode ( either from UNIX or > Windows) to generate the MCS files for the EEPROMs. Is there any way > to run the impact in batch mode in UNIX to generate the MCS files? I > was not able to get the information lookig at the help information > available. > You can make MCS files with promgen: $ promgen -h PROMGEN: Creates memory (PROM) file(s) from configuration (BIT) file(s) for use in programming a PROM. The PROM may then be used to configure one or more FPGAs. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 116409
On Mar 6, 8:58 am, Phil Hays <inva...@dont.spam> wrote: > Andy Peters wrote: > > On Mar 5, 1:11 pm, "Jean Nicolle" <jean.nico...@sbcglobal.net> wrote: > >> Is it possible to use an ISE project to compile for multiple devices? > > >> I happen to have a project that can target two different boards with > >> different FPGAs. Most of the files are the same, besides the UCF. Do I > >> have to create separate ISE projects? I'd rather have one project with > >> different variations. But that doesn't seem supported. Anybody can set > >> me wrong? > > > Use a Makefile. > > A makefile for this build can be a fairly good answer with dual core > computers becoming more common, as the two map and par jobs can be run in > parallel. Write a makefile and use: > > make --jobs=2 > > Make is a cool utility. Can be loaded with the Cygwin package on Windows, > and is native on Linux. For more information on make: > > http://www.gnu.org/software/make/ > > Using make doesn't prevent one from using a Tcl script(s) for the actual > builds as Jim suggested. If this was done the makefile might have just two > items (it might have more as well): > > ../bld1/board1.bit : *.vhd *.v board1.ucf build.tcl > <tab> xtclsh build.tcl board1 > > ../bld2/board2.bit : *.vhd *.v board2.ucf build.tcl > <tab> xtclsh build.tcl board2 > > Some explanation of this makefile: > > 1) The first line of each item is "the target" : "the sources". Make > checks to see that the target is newer than the sources. If not newer or > if the target does not exist, then make executes the commands on following > lines starting with tab characters. > > 2) " <tab> " is the tab character. Required by make before every command. > > 3) xtclsh is the Xilinx Tcl shell, used to execute the script. ISE8.2 or > later. > > 4) build.tcl is the script that builds the designs. This script is > expecting a parameter to define which board to target. > > Tcl is not as trivial to multithread as make is. On the other hand, Tcl is > a general purpose language, so it can be used for lots of other tasks that > make can't do, such as creating revision or timestamp values to be loaded > into registers, parsing report files, multiple .ucf files in a design, > etc. For more information on Tcl see: > > http://www.tcl.tk/about/features.html > > Or the Tcl section in the Xilinx manual. > > -- > Phil Hays (Xilinx, but writing my own words) Hi, I had already met the situation you are in now 3 years ago. The main culprit is that VHDL language lacks the capability of handling conditional statements. Its drawback of VHDL put small company engineers in a very disadvantageous place. The reason is in small company, one doesn't have manpower resources to develop a conditional statement program to permit VHDL to insert conditional statements. It is very hard for anyone to imagine without such powerful conditional statement handling software, Intel would develop a multiple core system. I mentioned the problem in VHDL group, but met huge opposing and even someone suggested to use C++, C language preprocessor program to handle VHDL problem, or use makefile. It is a shame for VHDL language. Finally I wrote a software to do the job. Since then, I can easily develop several versions for one project using one source file: product version, ChipScope debugging version, simulation version and so on. And more than that, I have put 4 project files into one big file, in other words, 4 project files are sharing one big VHDL file. Without the similar method, Intel cannot manufacture so many product lines. Generate/loop statements have very limited capability in reality. For example, it can only change signal's width in a module interface, but it cannot insert or delete any signals in the module interface. WengArticle: 116410
Hi everybody,
since one day I am fighting with a Xilinx CoreGen IP. I am using Mentor
Graphics Precision 2006a.101 and Xilinx ISE 9.1. I have a fifo IP
generated the Xilinx CORE Generator.
In my design, I make an instance of the fifo and can simulate it. For
precision, I added two lines to the compilation script:
add_input_file fifo18w16d.v
add_input_file -exclude fifo18w16d.edn
Both files were generated by the Xilinx CORE Generator.
After compilation and synthesis, I call ngdbuild and get the following
error message:
Checking timing specifications ...
Checking expanded design ...
ERROR:NgdBuild:604 - logical block 'inst_fifo/BU2' with type
'fifo18w16d_fifo_generator_v2_3_xst_1' could not be resolved. A pin name
misspelling can cause this, a missing edif or ngc file, or the
misspelling of
a type name. Symbol 'fifo18w16d_fifo_generator_v2_3_xst_1' is not
supported
in target 'virtex2'.
Partition Implementation Status
-------------------------------
No Partitions were found in this design.
-------------------------------
NGDBUILD Design Results Summary:
Number of errors: 1
Number of warnings: 0
One or more errors were found during NGDBUILD. No NGD file will be written.
Writing NGDBUILD log file "Xilinx_CoreGen.bld"...
What is wrong? BTW, this procedure works fine for dual ported RAM
created with the CORE Generator.
Thank You very much,
Markus Fras
Article: 116411
Weng
> Hi KJ,
> I have another question for you.
>
>> Q <= (C and D) or (not(C) and Q);
> 1. Is any combinational equation with target signal in both right part
> and left part of the equation a latch like your equations 3 or 4 show?
A latch is the most benign form.
There are oscillators (however when they occur by
accident, they are not necessarily this obvious):
Q <= not Q ;
There is also other strange latch-like behavior.
I don't have an equation for you, but I do remember
analyzing one - it was very interesting.
Cheers,
Jim
Article: 116412I think we will agree that a latch needs positive feedback from the output to at least one of the inputs. If the feedback is negative (Qbar to D, for example) you end up with an oscillator. Peter Alfke On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote: > Weng> Hi KJ, > > I have another question for you. > > >> Q <= (C and D) or (not(C) and Q); > > > 1. Is any combinational equation with target signal in both right part > > and left part of the equation a latch like your equations 3 or 4 show? > > A latch is the most benign form. > There are oscillators (however when they occur by > accident, they are not necessarily this obvious): > Q <= not Q ; > > There is also other strange latch-like behavior. > I don't have an equation for you, but I do remember > analyzing one - it was very interesting. > > Cheers, > JimArticle: 116413
On Mar 8, 7:57 pm, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > On 2007-03-08, Daniel S. <digitalmastrmind_no_s...@hotmail.com> wrote: > > > All the GbE PHYs I have seen have their datasheets available only under NDA. > > Just one datapoint here: We are using an AVnet board with a National > Semiconductor DP83861 10/100/1000 Ethernet PHY on it and the datasheet is > available for download from their homepage. So there are PHYs with public > documentation available. > > /Andreas Ok. I will try to get the data sheet this way. In the meantime, can you suggest the easiest way of establishing the Gigabit etherner connectivity between the FPGA and the host PC. I need speed in excess of 50 Megabytes / Sec. Should I go the EDk way or to try the verilog side. I have Virtex-4 FX so it has extensive support for Gigabit ethernet. Thanks.Article: 116414
Steve, Can you tell me a little bit more about what device you are targeting and the version of WebPACK you are using. Are you using any multiplier blocks or doing any multiplication operations and pipelining the output? -David "Steve Battazzo" <thesteveman_ice9@yahoo.co.jp> wrote in message news:m6KdnZIfoIUuVnLYnZ2dnUVZ_rmdnZ2d@comcast.com... > At the XST-synthesize stage, I'm getting this weird warning: > "Property use_dsp48" is not applicable for this technology. > I don't have anything in my code that I know of that calls for any such > thing.. it doesn't affect the program actually running on my board, but > I'm curious anyway. > > Anyone know what this means? > > Thanks, > > SteveArticle: 116415
On 2007-03-08, jrabbani@gmail.com <jrabbani@gmail.com> wrote: > Ok. I will try to get the data sheet this way. In the meantime, can > you suggest the easiest way of establishing the Gigabit etherner > connectivity between the FPGA and the host PC. I need speed in excess > of 50 Megabytes / Sec. Should I go the EDk way or to try the verilog > side. I have Virtex-4 FX so it has extensive support for Gigabit > ethernet. Thanks. It depends on what kind of application/data we are talking about. It is for example not that hard to send UDP data to a static IP address using a hardcoded MAC address in your design. The dataflow could be something like the following: Data in --> FIFO --> Add UDP/IP header --> Asynchronous FIFO --> --> CRC generator --> Ethernet PHY This setup should work well if you have a fast PC connected to your design either directly or through a switch. However, you should be prepared to lose a few packets here if your PC is not fast enough or does not allocate enough buffer space for UDP packets coming in at 50 MB/s. However, if you need something like TCP/IP or the ability to buffer data in an off-chip memory and send it to the PC on demand, you are facing a tougher problem. In this case it is probably worth to investigate what the EDK has to offer. If you are going the first route I would suggest that you look at the following lab exercise which has some good information (only for 10/100 Mb/s Ethernet but the only difference is that you are typically using 8 wires for data to a gigabit Ethernet PHY instead of 4): http://www.sm.luth.se/~maglun/lab33/lab33.pdf and http://www.sm.luth.se/~maglun/lab33/ In particular, they have an explanation of the Ethernet CRC and a couple of example CRC:s which is very valuable when you are trying to send an Ethernet packet through your own CRC generator. /AndreasArticle: 116416
On 7 Mar 2007 11:27:14 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >Without divulging any secrets (hell,I do not even work in that >division of Xilinx, so how would I know?): >The biggest problem in integrating an A/D converter is deciding on its >parameters. >Should it be a slow, high-precision sigma-delta type, or successive >approximation, or a fast flash converter? Single channel or multi- >channel? >The trouble is that these are irreversible decision. You cannot morph >a slow 12-bit converter into a fast 8-bit converter (like you do >easily in the digital domain). For a delta-sigma converter, I don't believe this is true. Its hardware is fundamentally a very fast, low-resolution (typically 1-bit!) ADC, coupled to a similar DAC, via an n'th order filter in a feedback loop to perform noise-shaping, ie to shift quantisation noise out of the desired frequency band into another part of the spectrum. This has to be followed by a band-limiting filter (in the digital domain), normally accompanied by decimation to the sample rate of interest. The dumbest implementation, a first order high pass filter in the feedback loop, is recognisable as an integrator - but typically a third order filter is employed. Now it's been a long time since I read Bob Adams' papers, but reading between the lines it seemed obvious that you could choose the noise-shaping filter to suit your application, selecting different ones for extremely low noise in a narrow bandwidth, or higher noise levels in a wider band, the product of the two parameters being roughly constant. The bandlimiting/decimation filter obviously has to track this choice. (Selecting between filters is safer than full programmability, a poor choice of filter in a feedback loop leads to instability!) - BrianArticle: 116417
On 7 Mar 2007 13:59:49 -0800, "axr0284" <axr0284@yahoo.com> wrote: >Hi, > I would like to know what are the common methods of introducing >delays as low as 10ps between two outputs in an FPGA. I do not >currently have a specific FPGA in mind. I am just looking for a >general answer. That sounds like 2mm of PCB trace to me. - BrianArticle: 116418
On 7 Mar 2007 14:51:25 -0800, "Alan Nishioka" <alan@nishioka.com> wrote: >On Mar 7, 2:26 pm, dipum...@hotmail.com wrote: >> I am using xilinx tools in an unix system to do the P&R and generate >> the bit file. I am using a batch mode script to go through the steps. >> Currently I am running impact in gui mode ( either from UNIX or >> Windows) to generate the MCS files for the EEPROMs. Is there any way >> to run the impact in batch mode in UNIX to generate the MCS files? >Under windows, impact creates a file called _impact.cmd in the current >working directory. I believe (from reading whatever log file it produces) Impact simply passes the task to a command-line utility called "promgen". I tried running Promgen (using the command line I found in that logfile) and it seemed to work OK. (ISE 7.1) That was under Windows, but I see no reason why it should be different in Linux. - BrianArticle: 116419
On Mar 7, 11:47 am, "news.t-online.de" <carlhermann.schleh...@t- online.de> wrote: > I just got a newsletter stating the Spartan3AN being available now. While > these Spartan3AN are market as "new non-volatile" FPGAs, this might (IMHO) > be misleading. For my understanding "non-volatile" would mean no > configuration on power-ON (as e.g. ACTEL AntiFuse) rather than Config-Eprom > being integrated in FPGA chip's housing (being a separate die as well). > Nevertheless this definitely is a nice appraoch, saving space and copper > traces on PCB. The parts aren't "available now." (We'd like to see the smaller 3A parts ...) Anyways, the Lattice XP devices, which have been around for quite awhile, have built-in configuration flash memory and start up a lot quicker than the 3AN devices. I haven't done a detailed side-by-side feature comparison, but it looks like one Xilinx advantage is that their flash can be used for both configuration and as part of the design; the Lattice memory is for configuration only. I dunno who's faster, who's got more resources, who's less expensive, etc. I do recall certain Xilinx representatives saying something like "on- board configuration memory means that we'll have to use an older process, meaning slower, more power-hungry parts, yadda yadda yadda." -aArticle: 116420
Markus Fras wrote: > Checking timing specifications ... > Checking expanded design ... > ERROR:NgdBuild:604 - logical block 'inst_fifo/BU2' with type > 'fifo18w16d_fifo_generator_v2_3_xst_1' could not be resolved. A pin name > misspelling can cause this, a missing edif or ngc file, or the > misspelling of > a type name. Symbol 'fifo18w16d_fifo_generator_v2_3_xst_1' is not > supported > in target 'virtex2'. Is there a third file in the coregen-directory? There might be an .ngc-file called fifo18w16d_fifo_generator_v2_3_xst_1.ngc. If so, you have to add this to your project as well (also with the -exclude option). The .edn is then just a wrapper for the .ngc, and is way smaller. I've had this problem before. Even if I explicitely tell CoreGen that I want it to create an EDIF-netlist for third-party tools, I always get an .edn and an .ngc, and I need them both. I don't remember this from earlier ISE-versions, but I might just not have tried all different settings. HTH, Sean -- My email address is only valid until the end of the month. Guess what it's going to be after that...Article: 116421
Dear all, while performing a Place and Route of a reconfigurable project (developed followinf the Early Access User Guide ug208) the par return this error: ERROR: CLock Buffer "Inst_Clockman/CLK0_BUFG_INST" is not placed after constraint resolution. It is a requirement that all clock buffers be "located" during constraint resolution. PLease coorect this before continuing". In the UCF file I placed the following constraint: INST "Inst_Clockman" AREA_GROUP = "DCM" INST "Inst_Clockman/DCM_INST" LOC = "DCM_X0Y1"; INST "Inst_Clockman/CLK0_BUFG_INST" LOC = "BUFGMUX7"; AREA_GROUP "DCM" MODE = RECONFIG; AREA_GROUP "DCM" GROUP = CLOSED; I also tried removing the INST "Inst_Clockman/CLK0_BUFG_INST" LOC = "BUFGMUX7"; but the error remain the same. The software I am using is ISE 8.2iSP1 with PR07 and the device is a Xilinx Spartan3 xc3s400. What could I do? Thank you very much LucaArticle: 116422
I am trying to deserialize a DDR signal in my Cyclone. For reasons I won't go into the DDR clock comes in off a general purpose I/O pin. I need a way of deserializing this signal, and want to increase the frequency of the DDR clock by 2 so I can use rising edge flip-flops. 1.) Can I somehow drive a PLL with a general purpose I/O 2.) Is there another way of deserializing the DDR signal. Currently I have a the DDR clock coming in my fpga and I not the clock so I can sample the DDR signal on the rising egde. ThanksArticle: 116423
Hi. I want to load the bitstream encryption key on a V4FX board. Using IMPACT and a Xilinx download cable, I can successfully load it (together with a design file). However, my board doesn't normally expose the JTAG pins to connect a Xilinx cable. Instead, it uses a proprietary interface. I can play XSVF files over this interface to program the bitstream. To create the XSVF I repeat the same steps that work with a Xilinx cable, recording to XSVF. However, playing this file on my board doesn't load the keys. Analysis of the XSVF suggests that IMPACT (ISE 8.1 SP3) forgets to include the JTAG commands for the key for some reason. At least, when recording to an ASCII SVF file, I can't locate the key anywhere. As alternative approach to the problem, I browsed the V4FX documentation for instructions on how to create a key loader program myself. Unfortunately the only hint I found is that ISC_PROGRAM can be (somehow) used to enter a so-called "key-access mode", without giving further details on the matter. I appreciate any information on that matter. Even just a sample (X)SVF containing the instructions for a key load would be of help to me. Thanks, MarcArticle: 116424
Hi "news reader", my humble perls in between.. news reader schrieb: > In the design I have 256 3-bit registers, every time I need to read or > write 16 of them (data_o0, 1, ...15). > The read/write address is not totally random. It seems that you have an algorithm that handles a deterministic distribution of the values to be accessed. Therefore you think you can implement it with logic only. I assume you are modeling an algorithm for a special matrix operation. > For example, assuming that I arrange the register into a 16X16 matrix, > data_o0 accesses among the zeros row or column. data_o1 may access from 20 of the > registers, but not 256, data_o2 may access from 30 of the variables, etc. The values do not give us much info. data_ox (x = 1, 2, ...) is accessing which elements and in which distribution? > If I code such that every output reads from the 256 registers, the final > logic will be overkill and highly redundant. You think that the distribution of elements can be accessed with pure logic. Therefore you tried to model your logic to cover every case, or you want to do it so. > If I use case statements to list each of the senarios, the RTL code may end > up 500 kilobyte. This is reasonable then. > Will design compiler synthesize a 500KB design efficiently? What means "efficience" for you? Speed or minimum logic? If minimum logic, then please share with us the algorithm you are trying to implement. > Will NCVerilog compile and simulate it efficiently? NCVerilog does not care about logic implementation. It defines the behaviour of the system, no matter how the objects are linked. > Are there any neater techniques to attack this problem? Since you have not given much data, I think you can implement this stuff with a RAM. Why don't you use a RAM? Then you can define the RAM addresses to model your matrix. You will generate addresses to define the positions for your matrix which mimics your algorithm. Utku.
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