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 comp.lang.vhdl Mike Treseler <mike.treseler@flukenetworks.com> wrote: Ive always thought of a good way to remember which one is which, but you gave it in a nutshell. Moore has more bubbles or "moore bubbles". I don't think I forget it ever again :) regards, juza : If you synchronize all inputs to the machine, : take your pick. It's all good. : Mealy has fewer bubble but busier arrows. : For a given Mealy description, you can make a Moore description : that generates the same hardware, so there's no difference in cost : except for ink to draw bubbles. : A synchronous hdl process is a superset of these models. : -- Mike Treseler -- JuzaArticle: 55701
lc wrote: > > What would be the simplest and smallest CPU core for an FPGA ? ftp://137.193.64.130/pub/mproz/mproz_e.pdfArticle: 55702
If you are getting glitches, then you have not synchronized at the outputs, rather you have some gating after
your flip-flops. To fix that, change your design so that all outputs come directly from a flip-flop with no
combinatorial gating after the flip-flop.
Wong wrote:
> Hi Mike,
> Yes, you are right to synchronize the outputs. But its still glithcy
> as the problem is not originate from this issue. It should be the P&R
> delays of the primitives in the FPGA. I think I needs tech support
> from the FPGA vendor. Thanks Mike.
>
> Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3EC3D03E.20100@flukenetworks.com>...
> > Wong wrote:
> >
> > > Here's the code. Its fine with the functional simulation but after
> > > P&R, I have the problems as mentioned. Thanks.
> >
> > The glitches are coming from your combinational outputs.
> >
> > Consider getting rid of next_state and the combinational process.
> > and putting all the code into a single case of current_state
> > in the synchronous process elsif clause.
> >
> > That would give you synchronous outputs by default.
> >
> > -- Mike Treseler
--
--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: 55703Herbert Kleebauer wrote: > > lc wrote: > > > > What would be the simplest and smallest CPU core for an FPGA ? > > ftp://137.193.64.130/pub/mproz/mproz_e.pdf That's pretty simple all right. -- 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: 55704
"LIJO" <lijo_eceNOSPAM@hotmail.com> skrev i en meddelelse news:b9vke7$nsqva$1@ID-159866.news.dfncis.de... > hi all, > can anyone tell me which state machine is good (Moore or Mealy).. Why? > > rgds, As Eric pointed out in a Mealy machine the output depends on the input and the current state and in a Moore the output solely depends on the current state. What needs to be added to this discussion is that, yes, a Mealy machine has "fewer bubbles" :-), but that does also mean that a Mealy implementation is often faster (each bubble counting as one clockcycle) than a Moore type. The problem is that the designer should probarbly remember to deglitch the outpur (through a flip-flop) to avoid unwanted glitches in the outputs. Best Regards RuneArticle: 55705
Can anyone point me to information on what the differences (if any) would be
between ES and production Xilinx parts? The specific device I'm looking at is an
XC2V3000-5FF1152CES.
Thanks in advance,
Mark
Article: 55706Ralph Mason wrote: > > "Ben Jackson" <ben@ben.com> wrote in message > news:U3Wwa.896193$S_4.913293@rwcrnsc53... >> In article <3EC422C8.567380EA@Xilinx.com>, >> Goran Bilski <Goran.Bilski@Xilinx.com> wrote: >> > >> >PicoBlaze from Xilinx should fit your need. >> >It's the smallest and simplest CPU core for a FPGA. >> >> I'm curious, why do they offer a PicoBlaze for Coolrunner but not for >> XC9500? Their comparison charts don't make those product lines look >> too different, beyond power consumption. > > I curious what purpose it actually serves??? > > Why would you want to use an expensive CPLD and external flash to perform > less functions than a $1 micro controller? It is sometimes very convenient to have a micro controller doing some tasks that would otherwise require nasty big state machines. And when you already have an expensive CPLD or FPGA, would you attach an external $1 micro controller and waste $10 PCB space? Regards, MarioArticle: 55707
Jan Panteltje wrote: > > > Design Summary > -------------- > Number of errors: 0 > Number of warnings: 27 > Number of Slices: 2,350 out of 2,352 99% > Number of Slices containing > unrelated logic: 37 out of 2,350 1% > Total Number Slice Registers: 281 out of 4,704 5% > Number used as Flip Flops: 280 > Number used as Latches: 1 > Total Number 4 input LUTs: 4,183 out of 4,704 88% > Number used as LUTs: 3,761 > Number used as a route-thru: 422 > Number of bonded IOBs: 3 out of 140 2% > Number of GCLKIOBs: 2 out of 4 50% > Total equivalent gate count for design: 38,728 > Additional JTAG gate count for IOBs: 240 > > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15" (output > > signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a route-thru. > > However, since it is driving a MUXF6, such transformation will not be carried > > out. > > And indeed it gives an error and asks me to RELOC or whatever something > that I cannot even locate as it has not mapped anything.... > This is puzzling. You say that there was a MAP error with the word "RELOC" in it, but the design summary indicates that no errors occurred and our CR database has no record of the word "RELOC" ever being reported in an error message. It would help if you provided the full text of the *error* message. Are you sure it wasn't a PAR error? The warning messages seem benign to me. It appears that the optimization of some MUXF5s was considered but rejected because of the connectivity restrictions between the MUXF5s and MUXF6s. The main question would be why the synthesis tool created such a structure in the first place. BTW, I disagree with previous statements about your device being over utilized. The key indicator is that unrelated logic packing is at only 1%. Generally, I don't see severe routability issues until this reaches 15-20% Regards, Bret Wade Xilinx Product ApplicationsArticle: 55708
John, FYI, the fast version of the Xilinx PCI-X core already uses both IFFs of the PCIX-IOBs. If you want to operate your circuit at PCI-X/133MHz later, you shouldn't use the spare input registers for other functions. Michael "John Daae" <john.daae@datarespons.no> wrote: > I am implementing a system using a PCI-X core from Xilinx and I want to to > use the spare input registers (the second DDR input register) that the core > is not using. I have tried using IOB attribute on the actual signals in my > VHDL code and I have tried IOB = TRUE constraint in the UCF file, but the > PAR seems to ignore these guidings. > > Any suggestions? > Is there a primitive for inputs register that I can instatiate? >Article: 55709
Mark, Contact your Xilinx FAE (or enter a hotline case) to get the errata sheet that goes with that part. If you did not get the errata sheet with that part (it had one!) you do not have what you need to know. Austin Mark Schellhorn wrote: > > Can anyone point me to information on what the differences (if any) would be > between ES and production Xilinx parts? The specific device I'm looking at is an > XC2V3000-5FF1152CES. > > Thanks in advance, > > MarkArticle: 55710
>I would say a counter and a table in block ram would be your smallest CPU, >with the bits from the block ram driving whatever processes need to run. You don't even need the counter if you make the ROM a bit wider. Use part of the ROM as the next-PC field. (Of course the counter may be free if the LUTs in front of the FFs are not otherwise used.) You can do branching if you make the ROM slightly wider. That is add a another address bit and feed your branch condition in there. Duplicate the code if you won't want to branch in that instruction. You can save ROM space if you OR the branch bit into an address bit. Use a MUX to select which bit if you have several you might want to inspect. Use several address bits if you want to check several conditions on the same instruction. You might be able to do similar games using the branch-on signals to load or reset the counter. Or AND/OR/XOR them into bits in the counter. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 55711
Rgr wrote:
> a Mealy machine has
> "fewer bubbles" :-), but that does also mean that a Mealy implementation is
> often faster (each bubble counting as one clockcycle) than a Moore type.
No. Timing can be the same for synchronous logic.
The only difference is the identifiers on the resulting flip-flops.
Consider a bubble 'S1' waiting for REQ to generate ACK in bubble 'S2'
Mealy sees this as an output on the arrow from S1
Moore sees this as and output decode on S2.
_ _ _ _
clk_| |_| |_| |_| |
__.____
REQ _/ . .[Input]
_. .
D S1_/S2. .[State Register input]
__.
Q _S1./S2.[State Register output]
. __.
ACK ____./ [Output]
The output logic can be either:
ACK <= state_d=S2; -- (next_)state S2 decode,
or:
ACK <= state_q=S1 and REQ; -- state S1 and REQ
-- Mike Treseler
Article: 55712If it doesn't have an assember.... Then it is a pain. If it has an assembler OR it has a c compiler, then it is really much more fun. Picoblaze has assembler support, and MicroBlaze has c support. Austin lc wrote: > > Hello, > > What would be the simplest and smallest CPU core for an FPGA ? > I saw a lot of cores that mimic existing controllers > but I would not mind to have something simpler. > Low LE count is my goal. > > Anybody had similar objectives? Any ideas ? > Would somebody point me in the right direction ? > > Thanks. > > Luis Cupido. > > P.S. - The application is logic intensive (a very large correlator) > however the system output happens only once every second. > Using logic for the output processing become tremendously big, > a total waist of resources for something that happens only once > every second.Article: 55713
I only use the second cnstruct if I want tos use for loops are case statements. The case statement is really usefull to make big multiplexers. For simple logic equations, the 'assign' is simpler and more readable because you don't need the always constructions before it. "geeko" <jibin@ushustech.com> schreef in bericht news:b9na79$l03s4$1@ID-159027.news.dfncis.de... > Hi all > I have some questions about the modelling of combinational logic > using verilog . an AND gate can be modelled using the wire construct as > shown below . > > > module ( a, b, y); > input a, b; > output y; > wire a, b, y; > assign y = a & b; > endmodule > > > The same circut can also be modelled with a reg construct . > > > > module ( a, b, y); > input a, b; > output y; > reg y; > wire a, b; > always @ ( a or b) > y = a & b; > endmodule > > > Which description is considered as the best.What exactly the physical > significance of a reg constuct > > cheers > > > > > >Article: 55714
"Mario Trams" <Mario.Trams@informatik.tu-chemnitz.de> wrote in message news:ba2vir$3tt$1@narses.hrz.tu-chemnitz.de... > Ralph Mason wrote: > > > > > "Ben Jackson" <ben@ben.com> wrote in message > > news:U3Wwa.896193$S_4.913293@rwcrnsc53... > >> In article <3EC422C8.567380EA@Xilinx.com>, > >> Goran Bilski <Goran.Bilski@Xilinx.com> wrote: > >> > > >> >PicoBlaze from Xilinx should fit your need. > >> >It's the smallest and simplest CPU core for a FPGA. > >> > >> I'm curious, why do they offer a PicoBlaze for Coolrunner but not for > >> XC9500? Their comparison charts don't make those product lines look > >> too different, beyond power consumption. > > > > I curious what purpose it actually serves??? > > > > Why would you want to use an expensive CPLD and external flash to perform > > less functions than a $1 micro controller? > > It is sometimes very convenient to have a micro controller > doing some tasks that would otherwise require nasty big > state machines. And when you already have an expensive > CPLD or FPGA, would you attach an external $1 micro controller > and waste $10 PCB space? You missed the point. A 256 marocell cool runner IS *VERY* pricey and big compared to a $1 uC. I was speaking totally of the picoblaze core for Coolrunners. In a FPGA design it makes sense. Putting down an expensive CPLD and a rom just to run picoblaze, so sense whatsoever (you might as well use a 50k spartan) Even if you already HAVE a cool runner on there I don't see anyone EVER wanting to pay for a ROM / extra 256 marcocells when they could just use a Microcontroller (better tools, more capable, cheaper, and if you include the need for a ROM with the CPLD then it's the same amount of board space). A marketing exercise pure and simple I think. RalphArticle: 55715
click on http://support.xilinx.com/support/techxclusives/leftover-techX11.htm and see some examples in the second half of that story. Just one catch: The "bottom half" of the ROM also uses synchronous read, so its output is one clock tick delayed from the "top half". What is a big advantage in the top half is a disadvantage in the bottom half... Peter Alfke, Xilinx Applications Hal Murray wrote: > > >I would say a counter and a table in block ram would be your smallest CPU, > >with the bits from the block ram driving whatever processes need to run. > > You don't even need the counter if you make the ROM a bit wider. > Use part of the ROM as the next-PC field. (Of course the counter > may be free if the LUTs in front of the FFs are not otherwise used.) > > You can do branching if you make the ROM slightly wider. That is > add a another address bit and feed your branch condition in there. > Duplicate the code if you won't want to branch in that instruction. > > You can save ROM space if you OR the branch bit into an address bit. > Use a MUX to select which bit if you have several you might want > to inspect. Use several address bits if you want to check several > conditions on the same instruction. > > You might be able to do similar games using the branch-on signals > to load or reset the counter. Or AND/OR/XOR them into bits in the > counter. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.Article: 55716
Ralph Mason wrote:
> "Mario Trams" <Mario.Trams@informatik.tu-chemnitz.de> wrote in message
>>
>> It is sometimes very convenient to have a micro controller
>> doing some tasks that would otherwise require nasty big
>> state machines. And when you already have an expensive
>> CPLD or FPGA, would you attach an external $1 micro controller
>> and waste $10 PCB space?
>
> You missed the point. A 256 marocell cool runner IS *VERY* pricey and big
> compared to a $1 uC. I was speaking totally of the picoblaze core for
> Coolrunners. In a FPGA design it makes sense. Putting down an expensive
> CPLD and a rom just to run picoblaze, so sense whatsoever (you might as
> well use a 50k spartan)
>
> Even if you already HAVE a cool runner on there I don't see anyone EVER
> wanting to pay for a ROM / extra 256 marcocells when they could just use a
> Microcontroller (better tools, more capable, cheaper, and if you include
> the need for a ROM with the CPLD then it's the same amount of board
> space).
Hi Ralph,
I totally agree with you in that point (when it is used exclusively
used for the micro controller).
But does Xilinx actively promote such a core as an exclusive
component? I guess it is a more general core and when one is
using it alone it's not the problem of Xilinx...
Regards,
Mario
--
----------------------------------------------------------------------
Digital Force / Mario Trams Mario.Trams@informatik.tu-chemnitz.de
Mario.Trams@wooden-technology.de
Chemnitz University of Technology http://www.tu-chemnitz.de/~mtr
Dept. of Computer Science Tel.: (+49) 371 531 1660
Chair of Computer Architecture Fax.: (+49) 371 531 1818
----------------------------------------------------------------------
Article: 55717"Mario Trams" <mtr@informatik.tu-chemnitz.de> schrieb im Newsbeitrag news:ba3m1f$qpd$1@narses.hrz.tu-chemnitz.de... > Ralph Mason wrote: > > > "Mario Trams" <Mario.Trams@informatik.tu-chemnitz.de> wrote in message > >> > >> It is sometimes very convenient to have a micro controller > >> doing some tasks that would otherwise require nasty big > >> state machines. And when you already have an expensive > >> CPLD or FPGA, would you attach an external $1 micro controller > >> and waste $10 PCB space? > > > > You missed the point. A 256 marocell cool runner IS *VERY* pricey and big > > compared to a $1 uC. I was speaking totally of the picoblaze core for > > Coolrunners. In a FPGA design it makes sense. Putting down an expensive > > CPLD and a rom just to run picoblaze, so sense whatsoever (you might as > > well use a 50k spartan) > > > > Even if you already HAVE a cool runner on there I don't see anyone EVER > > wanting to pay for a ROM / extra 256 marcocells when they could just use a > > Microcontroller (better tools, more capable, cheaper, and if you include > > the need for a ROM with the CPLD then it's the same amount of board > > space). > > Hi Ralph, > > I totally agree with you in that point (when it is used exclusively > used for the micro controller). > > But does Xilinx actively promote such a core as an exclusive > component? I guess it is a more general core and when one is > using it alone it's not the problem of Xilinx... > > Regards, > Mario > > -- > ---------------------------------------------------------------------- > Digital Force / Mario Trams Mario.Trams@informatik.tu-chemnitz.de > Mario.Trams@wooden-technology.de > Chemnitz University of Technology http://www.tu-chemnitz.de/~mtr > Dept. of Computer Science Tel.: (+49) 371 531 1660 > Chair of Computer Architecture Fax.: (+49) 371 531 1818 > ---------------------------------------------------------------------- As the CPLDs are reprogrammable, they could be used as a controller in a board test mode. A prom or sram should be availlable though. Imagine an embedded system with a flash connected to a cpld. A special design for the cpld for downloading the flash from the pc would be quite resource saving. After downloading the flash, the main cpld configuration could be programmed. Poor thing is that the coolrunners2 only can be reprogrammed for 1000 times. MIKEArticle: 55718
On a sunny day (16 May 2003 09:47:41 -0700) it happened bret.wade@xilinx.com (Bret Wade) wrote in <465bd4b1.0305160847.5239b392@posting.google.com>: >> And indeed it gives an error and asks me to RELOC or whatever something >> that I cannot even locate as it has not mapped anything.... >> > > >This is puzzling. You say that there was a MAP error with the word >"RELOC" in it, but the design summary indicates that no errors >occurred and our CR database has no record of the word "RELOC" ever >being reported in an error message. It would help if you provided the >full text of the *error* message. Are you sure it wasn't a PAR error? You are right: Sorry am in Linux now (middle of the night) but I cut and paste from __projectnav.log, it seems to hold many things I tried. So RLOC, not RELOC.. Overall effort level (-ol): 2 (set by user) Placer effort level (-pl): 2 (set by user) Placer cost table entry (-t): 1 Router effort level (-rl): 2 (set by user) Extra effort level (-xe): 0 (set by user) ERROR:Place:1993 - Components udc0_uf10_N324 and udc0_N1466 are using the F5/F6MUX resources. The component udc0_uf10_N324 is part of a carry chain macro. Please RLOC components udc0_uf10_N324 and udc0_N1466 together. Total REAL time to Placer completion: 13 secs Total CPU time to Placer completion: 13 secs Generating PAR statistics. Dumping design to file test.ncd. >The warning messages seem benign to me. It appears that the >optimization of some MUXF5s was considered but rejected because of the >connectivity restrictions between the MUXF5s and MUXF6s. The main >question would be why the synthesis tool created such a structure in >the first place. Anyways the latest I tried (then I left it) had this result: panteltje:/big/digilentic/viaveri-p1# cat _impact.log iMPACT log file Started on 2003/05/13 22:57:11 AutoDetecting cable. Please wait. CB_PROGRESS_START - Starting Operation. Connecting to cable (USB Port). Cable connection failed. Connecting to cable (Parallel Port - LPT1). Cable connection established. Elapsed time = 0 sec. '1': Loading file 'test.bit' ...done. ------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------ PROGRESS_START - Starting Operation. Validating chain... Boundary-scan chain validated successfully. '1':Programming device...done. '1': Programming terminated, Done did not go high. PROGRESS_END - End Operation. Elapsed time = 8 sec. ***** Closing iMPACT program. ***** > >BTW, I disagree with previous statements about your device being over >utilized. The key indicator is that unrelated logic packing is at only >1%. Generally, I don't see severe routability issues until this >reaches 15-20% Yes, that is at least good news, thank you for the reply. Jan >Regards, >Bret Wade >Xilinx Product Applications >Article: 55719
Martin, As my colleague has pointed out, the change in the slew rate is very much dependent on your load and so should be simulated with IBIS or SPICE. We (and other FPGA companies) do publish tables of IO adders for various IO standards, slew rates, and drive strengths. These are used to determine the tCO of the device for different cases, although assuming a standard load such as 10 pF for LVTTL. While this can give you an idea of the tCO difference between fast and slow slew rate, analog simulation is necessary for full understanding. There is a difference between edge rate and tCO variation (for example a 2 ns delay does not mean that the edge rate is 2 ns longer) but this can help you determine if the tCO of the device with slow slew rate on will meet your requirements. For example, page 4-57 of the Stratix Handbook shows the IO adders for various IO standards when fast slew rate is used, while 4-59 shows the IO adders when slow slew rate is used. The Stratix handbook is available here: http://www.altera.com/literature/lit-stx.html?xy=dev_sdh Also please note that Quartus II software will show different input and output buffer delays depending on what IO standard is used, but again assuming the standard load for that IO standard. Sincerely, Greg Steinke gregs@altera.com "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:<c2Kta.61402$e8.646243@news.chello.at>... > Greg, > thanks for the information. It would be nice if the change of the slew rate > could be stated in the datasheet. You don't always want to run a simulation > (with tools you don't have access to) to get a simple information like: > When I turn the slow sr on, do I meet my timing e.g. for an async. ram? > > Sorry for my ignorance about the IBIS models on the web. > > MartinArticle: 55720
I agree with Greg ( isn't that nice, X and A agreeing?) but let me add something that again applies to X and A and others: At the modern transition times, many if not most interconnects must be seen as transmission lines, and not as lumped capacitive loads. So, a long trace is not a large capacitive load, but rather a 50 Ohm (?) transmission line = a resistive load, without any (!) capacitance and the edge rate remains pretty steep. But you better terminate that transmission line somewhere, or you get very bad signal integrity... Just my $ 0.02 worth. Peter Alfke, Xilinx Applications ===================== Greg Steinke wrote: > > Martin, > As my colleague has pointed out, the change in the slew rate is very > much dependent on your load and so should be simulated with IBIS or > SPICE. We (and other FPGA companies) do publish tables of IO adders > for various IO standards, slew rates, and drive strengths. These are > used to determine the tCO of the device for different cases, although > assuming a standard load such as 10 pF for LVTTL. While this can give > you an idea of the tCO difference between fast and slow slew rate, > analog simulation is necessary for full understanding. There is a > difference between edge rate and tCO variation (for example a 2 ns > delay does not mean that the edge rate is 2 ns longer) but this can > help you determine if the tCO of the device with slow slew rate on > will meet your requirements. > > For example, page 4-57 of the Stratix Handbook shows the IO adders for > various IO standards when fast slew rate is used, while 4-59 shows the > IO adders when slow slew rate is used. The Stratix handbook is > available here: > http://www.altera.com/literature/lit-stx.html?xy=dev_sdh > > Also please note that Quartus II software will show different input > and output buffer delays depending on what IO standard is used, but > again assuming the standard load for that IO standard. > > Sincerely, > Greg Steinke > gregs@altera.com > > "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:<c2Kta.61402$e8.646243@news.chello.at>... > > Greg, > > thanks for the information. It would be nice if the change of the slew rate > > could be stated in the datasheet. You don't always want to run a simulation > > (with tools you don't have access to) to get a simple information like: > > When I turn the slow sr on, do I meet my timing e.g. for an async. ram? > > > > Sorry for my ignorance about the IBIS models on the web. > > > > MartinArticle: 55721
Hi Sirs/friends, I wanted to know how to encrypt a vhdl??? . how it is decrypted??? i recently heard that IP core company provide are encypted .how does this work???? waiting for reply praveenArticle: 55722
Hello Sirs/Friends I wnated to know what all test condition to be included in the testbench for testing of the PCI core so that i can tell that core is fully PCI2.2 compliant. Any reference/article refer will be great. waiting for reply praveenArticle: 55723
On 17 May 2003 00:50:42 -0700, praveenkumar1979@rediffmail.com (praveen) wrote: >Hi Sirs/friends, >I wanted to know how to encrypt a vhdl??? . how it is decrypted??? i >recently heard that IP core company provide are encypted .how does >this work???? Each simulator has an encryption/decryption algorithm. You run the files through the simulator with a special option and the simulator generates encrypted files. Then you can give those encrypted files to someone who has the same simulator and when they run the simulation the simulator decrypts the files internally and runs them. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 55724
praveenkumar1979@rediffmail.com (praveen) wrote in message news:<ff8a3afb.0305170028.3c941bf2@posting.google.com>... > Hello Sirs/Friends > I wnated to know what all test condition to be included in the > testbench for testing of the PCI core so that i can tell that core is > fully PCI2.2 compliant. > Any reference/article refer will be great. > > waiting for reply > praveen Hi praveen, pci-sig provides some checklist on every specification. If you conver all these functions, then u could mark your core as pci2.0 compliant refer www.pci-sig.com Regards, Muthu
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