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
Austin, > >Get off that boat: I have admitted it many times now. >It is you who seems to persist in dragging it on, >and on, and on, and on, and on..... > Perhaps when you stop posting the same poorly reasoned arguments over and over again, I'll stop correcting them over and over and over again. You claim to have "admitted" that the input capacitance is a problem, yet here you go again with your denials: >> >> You disagreed with me on this issue, so in subsequent posts >> I refuted the various arguments that you made contending that >> the high V2 C_COMP value is unavoidable/not a problem/etc. > >It is. > If you can't form a coherent argument, don't bother posting grade school "is too, is too, is too" nonsense. > >Since I can not see their data sheet (they block Xilinx domain), >I have no means of verifying your claim. > That information was in my very first post; you ignored it, continued denying it, yet still can't be bothered to check? Get a real excuse. Do you honestly expect us to believe that you have no Internet access outside of work? Or, that nobody at Xilinx keeps up on competitor's products? >> > >> >Our parts meet the LVDS standard, they work. >> > >> What about the other specs I have mentioned, such as HyperTransport, >> that have a tighter Cin or slew rate specification? > >Then we don't meet the "specs". Wasn't that simple? But we do >interoperate, and many people choose to do so. > Interoperate where? In one reference design, with one vendor's parts? Or, in all the potential configurations considered by the standards committee when they wrote the spec? May the spirits of the all the anonymous standards weenies, who worked so hard to incorporate those specifications that you so blithely dismiss, haunt your designs until you repent. > >No, it is just physics. Can't probe anyones 840 Mbs lines >without affecting them. > How can you argue on one hand that the ~10pf total Cin of your receiver inputs is not a problem, yet claim the fraction of a pf imposed by a decent probing scheme will somehow be significant in the same system? A well designed resistive coupler, properly packaged, will work at OC-192 rates and beyond. > >Gee, I designed digital microwave radios for 5 years, and I never could >"see" anything. Only could sniff at it with a spectrum analyzer. >Everything was simulated. Guess where we are all headed? > You may be stuck with doing simulations at the chip level, except for perhaps the guys doing wafer probe for low level device model correlations, but the users of your parts still have the luxury of testing and measuring directly in the real world. We will continue to use those tools that are most appropriate to the task at hand, rather than blindly placing our faith in IBIS models and simulators alone. BrianArticle: 61626
Hi Martin, Thanks for your reply. I'm a University student. I'm very familiar with HDL, I've already done my code in Verilog, and I just need to program the device so I can test and make sure my code is working. I'm actually very familiar with Actel FPGAs, but never used Xilinx before. System ACE and boot prom stuff is pretty new to me. The myriad of information on the Xilinx website is overwhelming, and that is why I wasn't sure where to start. I'll take a look at those materials you've pointed to, but I've already scanned through AVNET documentation that came with the board, and it was not very clear what plugs into where and how to 'quickly' get started. > Did you get a JTAG cable? So once I get Parallel IV cable, that plugs from my parallel port to JTAG directly? Is there a 'programmer' that I need? Also, I have ISE installed.Article: 61627
John Providenza wrote:
> I'm working on a design that's using multiple DCMs along
> with DDR i/o registers. The main input clock is 500MHz
> going into a DCM with the CLKIN_DIVIDE_BY_2 flag set
> so it's immediataly cut down to 250MHz. The DCMs used in
> the design also have CLKOUT_PHASE_SHIFT=VARIABLE.
>
> To drive my DDR i/o flops, I'm currently using both the CLK0 and
> CLK180 pins (running at 250MHz).
>
> The original designer flowed the DDR data though the chip using
> both clock edges, ie, the incoming "posedge" data went down a
> "posedge" data pipeline to flow back out the DDR output. The
> incoming "negedge" data went down a "negedge" pipeline. The
> original design did NOT use CLK0 and CLK180 for these two
> data paths. Instead, the designer used "posedge" and "negedge"
> in the Verilog. The major problem comes in the control and
> data signals that cross the two domains. Because of the potential
> duty cycle degradation,
Howdy John,
I have to admit some ignorance here, but I won't let that stop me from
later making some guesses about what is going on :-)
By duty cycle degradation, are you referring to what the DCM introduces,
or something with regard to the clock tree?
The datasheets claims that the DCM "duty cycle precision" is +/-150ps,
while the phase offset between DCM outputs is +/-140ps... and the jitter
out of CLK180 is +/-50ps worse than just CLK0. So it seems like you are
just going to be trading one problem for another problem here.
> the P&R tools don't achieve timing
> closure consistently.
>
> As an experiment, I changed the design to use CLK0 and CLK180 for
> the internal flops. I was:
> a) pleased when the P&R timing was better
I can't say I'm too surprised at that. Or rather, I can imagine why
that might be... if you open it up in FPGA editor, are there now
distinct sections of the devices that seem to be run exclusively off
CLK180 while other areas run exclusively off CLK0? If so, by diving up
the clocks, you may have effectively helped the tools floorplan the
design. Previously, everything was on a single clock tree, so it may
have mixed the two pipelines willy-nilly, making timing more difficult
to meet.
> b) surprised when the design no longer worked.
The only idea I have is to repeat Ray's mantra of being careful about
going back and forth between domains that are on different outputs of
the DCM.
Well, I take that back. Another idea is to floorplan the original
design at the top level: divide the device in half, one for each
pipeline, and see if you get noticeably better timing results.
Good luck,
Marc
Article: 61628
You can do it, and it is fairly simple. The shortcut method is to partition the
logic by using keep buffers (syn_keep attributes in synplify). The synthesizer
will preserve the signals with the keep buffer, which pushes those signals onto
LUT outputs. The lut contents are then specified with logic equations and the
luts are inferred. For example:
attribute syn_keep of d:signal is true;
attribute syn_keep of h: signal is true;
begin
d<= a and b and c;
h<= e and f and (not g);
out<= d or h;
forces the synthesis to put the equation for d in one lut, the equation for h in
one lut and out in a third lut. Actually what it does is force the outputs d,
and h to be lut outputs. If a,b and c come from flip flops or have syn_keeps on
them then you fully force the LUT. If you leave those off, the the synth is free
to move those. This gives you a method of controlling construction without
resorting to instantiation.
Synplicity also provides a mechanism for creating a component tht you can put an
fmap on forcing it to be a LUT. In this case, the LUT has to be a separate
component. This one can be RLOC''d. To do this, you create a separate
component, in this case an AND3, and include an xc_map=lut attribute on the
component. The architecture of the component has the boolean equation for the
LUT in it.
--FMAP'd and3
library IEEE;
use IEEE.std_logic_1164.all;
entity fmap_and3 is
port ( a, b, c : in std_logic;
z : out std_logic);
end fmap_and3;
architecture rtl of fmap_and3 is
attribute xc_map : STRING;
attribute xc_map of rtl : architecture is "lut";
attribute syn_hier: string;
attribute syn_hier of rtl:architecture is "hard";
begin
z <= a and b and c;
end rtl;
This method depends on your naming to make it readable. Naming is not hard for
simple logic functions, but can be a bit of a pain when the 4 inptu equation gets
complicated.
A third method is instantiating the LUT4, LUT3 or LUT2 component. In this case,
you dont' have a separate component to define, but you do have to supply the LUT
contents in the form of a hex string in two places: once for the INIT=attribute
which gets passed onto the edif netlist but not to simulation, and once to the
INIT generic which is used for simulation, but not passed to the netlist. As I
understand it, the latest version of synplify passes the INIT generic to the
netlist, but that is not portable. Great care has to be taken with this method
to make sure the simulation matches the synthesized hardware. It is also
extraordinarily error prone and difficult to read and maintain. This can be
worked around by writing a function to parse a boolean expression and convert it
to the appropriate INIT strings, but it is not trivial to write.
The first method gives you structure but no handles for naming or placing the
LUTs. The second is one I use for many of my library macros, as it permits
attachment of an RLOC placement attribute so you can get control over placement.
It does however result in a large library of small combinatorial functions which
can become awkward to maintain. The third is generally too hard to use and
maintain without a good INIT string generation function, however it does not
require a large library of 2,3 and 4 input functions. It is hardly usable
without the boolean to INIT function however.
Hal Murray wrote:
> >I tried to instantiate a LUT the other day and I couldn't figure out
> >the "right" way to do the Verilog for Synplify since there are INIT
> >parameters for simulation and xc_props="INIT=xxxx" for synthesis as
> >far as I can tell. I had something that looked un-LUT-like in the HDL
> >Analyst technology viewer so I didn't pursue that furhter.
>
> This seems like a good addition to the tools discussion in other
> threads.
>
> There really should be a simple way to say something like:
> Generate this signal in a LUT (or whatever) with these inputs.
> Possibly constraining the location and/or locking some inputs to
> particular ports.
> The idea is that the system will figure out the details from the
> info it already has.
>
> --
> 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.
--
--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: 61629
The mapper seems to be pretty good at respecting LUTs and not changing them.
rickman wrote:
>
> Actually, I don't think logic primatives will work since the back end
> mapper can redo logic at will. The keep attribute is what is required
> to define the LUTs and even that is not guaranteed since it only results
> in a wire being kept; the LUT can still be split if other logic uses the
> same inputs.
--
--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: 61630
I'm not sure I caught your requirement completely. As I understand it, you need to detect
when there are 9 0's or 9 1's starting at a byte boundary?
That can be done with a bit of logic and a carry chain:
the lsb inverts the remaining bits if it is zero, otherwise the remaining bits are passed to
the carry chain unchanged. the carry chain gets the conditionally inverted bits starting at
LSB+1, and at the 9th bit you look at the carry chain output (the carry in at the base of
the chain is also a '1'). If all the bits match the LSB, you get a '1' on the carry chain
output. This is easiest to code with instantiated MUXCY's rather than pushing on a rope to
get the synthesizer to figure out you want to use the carry chain as a wide and gate. Not
sure if this meets your requirement or not, but it is illustrative of how you might tackle a
similar problem with a perhaps less than obvious approach.
John_H wrote:
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7B3F59.191901A4@yahoo.com>...
> > My experience has been that it does not much matter how you code
> > combinatorial logic like this. The tools run it through a grinder and
> > produce an optimal version (in its own mind). When I want to optimize
> > like this, I either use a "keep" attribute on the wire, or sometimes you
> > can instantiate primitives. For logic I don't think primitives work
> > since gates just get remapped.
>
> I overuse the syn_keep attribute and I hate the idea of instantiating
> LUTs. My Carnot skills aren't exactly used regularly.
>
> > But I still don't understand your code. Why does the outer loop range
> > over 64 values.
>
> I've had problems with bit ranges in the past where [i+4:i] is a
> complaint. Perhaps this isn't an issue with for loops but I've
> learned to avoid them in general logic. They do work fine in generate
> blocks, however. I stepped through every bit to make a comparison to
> the adjacent bit; 3 adjacent comparisons lumped into one variable
> (with an eventual syn_keep) would give me 4-input functions that
> should pack into LUTs. The complex end of the inside loop is so that
> the three "LUTs" per byte are 4-input, 4-input, and 3-input functions.
>
> > I would code two nested loops where the outer loop
> > ranges over the 8 outputs and the inner loop ranges over the 9 inputs
> > for each output. Or just skip the inner loop and use two outputs from
> > two sets of four inputs feeding a 3 input function and use keeps on the
> > first two output arrays. Maybe that is what you are doing, but I can't
> > figure out the code easily.
> >
> > I see you are incrementing the i variable by j and ranging j in the
> > second loop by some complex control expression. Can't you just
> > increment i by 8?
> >
> > for( i=0; i<64; i=i+8 ) begin
> > k = i % 8;
> > for( j=0; j<4; j=j+1 ) begin
> > runBitsA_[k] = runBitsA_[k] & bytePlus1[i+j];
> > runBitsB_[k] = runBitsB_[k] & bytePlus1[i+j+4];
> > end
> > runByte_[i] = runBitsA_[i] & runBitsB_[k] & bytePlus1[i+9];
> > end
> >
> > Put the keep on runBitsA_ and runBitsB_ and you should get your two
> > level structure.
>
> This works very well for runs of ones only. I need to identify runs
> of ones or runs of zeros. The technique can be expanded to my needs
> resulting in runBitsA, B, and C where one of them needs to cover 2
> comparisons, not 3 like the others. ...which is really is the
> approach I was coding but using consecutive bits in a vector rather
> than {A,B,C} and using the one statement rather than 3 to make the
> assignments, dealing with the 2 comparison exception by terminating
> the inside loop early.
>
> Thanks for the help.
--
--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: 61631"mintchoco" wrote: > I'm a University student. I'm very familiar with HDL, I've already > done my code in Verilog, and I just need to program the device so I > can test and make sure my code is working. I'm actually very familiar > with Actel FPGAs, but never used Xilinx before. System ACE and boot > prom stuff is pretty new to me. The myriad of information on the > Xilinx website is overwhelming, and that is why I wasn't sure where to > start. > > I'll take a look at those materials you've pointed to, but I've > already scanned through AVNET documentation that came with the board, > and it was not very clear what plugs into where and how to 'quickly' > get started. > > > Did you get a JTAG cable? > So once I get Parallel IV cable, that plugs from my parallel port to > JTAG directly? Is there a 'programmer' that I need? Also, I have ISE > installed. OK, good. Then it sounds like it shouldn't be all that difficult for you to get going. Keep in mind that there are architectural differences between what you know and a VirtexII. Yes, the parallel cable IV (or III) for that matter, goes between the parallel port of your PC and the JTAG port on the board. If you have the small board with the XC2V40 it would be J100, next to the RS232 port on the board itself (I just happen to have a small collection of dev boards). There are several ways to program a Xilinx FPGA: 1- Master Serial 2- Slave Serial 3- Master SelectMAP (Parallel) 4- Slave SelectMAP (Parallel) 5- JTAG You'll find details in the "Configuration" section of the User Guide I pointed out to you. Xilinx FPGA's have volatile configuration memory. Regardless of which programming technique you use, if power goes out they wake-up without a configuration. There is a hardware option to use battery backup to retain configuration data as well. Check the docs. So, if you don't use the battery option you either use FLASH, SystemACE or other means of preserving and loading the bitstream during power-up (like a microprocessor with separate storage). These various means of bistream loading can use all of the above techniques to get the bistream loaded. However, the first four are the most common. The main difference between the serial and parallel loading methods is, of course, speed. Parallel can reach clock rates of around 60MHz. With an eight-bit bus you can load a 1 million gate FPGA real fast (only about 4 megabits required). Serial is probably a better option for a board with more than one FPGA where you need to create a configuration chain and load speed might not be crucial. JTAG and Serial is what you can do with either parallel cable. They are called "parallel" cables because of how they connect to your PC. There's a programming module called "MultiLynx" which can also do Parallel SelectMAP but it doesn't seem to be favored. This one connects to your PC via USB. You'd think it'd be the better way to go, but the FAE's I've talked to did not recommend it. Don't know why. With both JTAG and Serial SelectMAP you use a program shipped with ISE called IMPACT. Use the tools to synthesize, map, place and route your code. IMPACT would then take your "*.bit" file and either program the FPGA directly or an attached Xilinx FLASH chip which would, in turn, load the FPGA to run your code. I hope that gives you a better picture of what you are up against. The board should have shipped with a couple of test bitstreams you could practice loading. Oh, yes, if you didn't know, you need to create a UCF file where you'd assign your pins. Being that this is a development board, you don't want to let the tools assign pins at random 'cause you don't know where they might land. You don't need to edit the UCF file by hand, you can use the PACE utility to help you define the pinout (I prefer editing by hand though). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61632
Hi,
Does anyone have a schematic for the Altera byteblaster II cable or
has anyone developed a programmer for programming the ALtera EPCS1/4
family of serial configuration devices.
I am designing a board and I want to design the programmer into the
system.
Regards
Ben
Article: 61633When you write VHDL (or Verilog for that matter), do you visualize a schematic with wires, gates, flops, latches, muxes, etc., or do you use some other way of thinking about it? KevinArticle: 61634
"Kevin Kilzer" wrote: > When you write VHDL (or Verilog for that matter), do you visualize a > schematic with wires, gates, flops, latches, muxes, etc., or do you > use some other way of thinking about it? I don't know about visualizing (I do a lot of pencil drawings), but you are describing hardware. If you loose that focus you are bound to create monstruous designs that will not perform well at all. If you are a hardware guy it is a subconscious thing to simply think in those terms. I typically start with the hardware I want to create and simply use HDL to describe it. You can either rely on inference (which can be dangerous) or explicitly instantiate what you need. I tend to favor actually wiring-up what I want or using inference when I know that the tools won't screw it up. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61635
On Wed, 08 Oct 2003 05:49:40 GMT, Kevin Kilzer <kkilzer.remove.this@mindspring.com> wrote: >When you write VHDL (or Verilog for that matter), do you visualize a >schematic with wires, gates, flops, latches, muxes, etc., or do you >use some other way of thinking about it? I don't think about gates and muxes, because the FPGAs I use have LUTs. So I think about clouds of LUTs and flip flops. The only significant thing (for my application) about a cloud of LUTs is the depth, which determines the delay. Regards, Allan.Article: 61636
Ray Andraka <ray@andraka.com> writes: <snip> > A third method is instantiating the LUT4, LUT3 or LUT2 component. In > this case, you dont' have a separate component to define, but you do > have to supply the LUT contents in the form of a hex string in two > places: once for the INIT=attribute which gets passed onto the edif > netlist but not to simulation, and once to the INIT generic which is > used for simulation, but not passed to the netlist. As I understand > it, the latest version of synplify passes the INIT generic to the > netlist, but that is not portable. Great care has to be taken with > this method to make sure the simulation matches the synthesized > hardware. It is also extraordinarily error prone and difficult to > read and maintain. This can be worked around by writing a function to > parse a boolean expression and convert it to the appropriate INIT > strings, but it is not trivial to write. > <snip> >... The third is generally too hard to use and maintain without > a good INIT string generation function, however it does not require a > large library of 2,3 and 4 input functions. It is hardly usable > without the boolean to INIT function however. > Like this one? I rememebred seeing this mentioned a few weeks ago - a quick google and I found a link to it... from andraka.com of all places :-) [ Ray, you might want to update the link ] http://www.rockylogic.com/freebies/freebies.html Scroll down to "Locking Logic to a Single Xilinx Virtex LUT" Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 61637
Hello again, Can a radix-4 fft be used to construct any type of radix-2 fft. e.g. can I manipulate a 64 pt radix-4 fft to give me a 128 pt radix-2 fft ? If so, is the radix-2 fft of any use in dsp as it usually results in larger and slower ffts than the radix-4 version. As always thanks for all replies. Bob Carter -- My ignorance is shameful, but I would rather be ashamed than ignorant. Better, I would rather be neither !!!!Article: 61638
Hi Martin, I'm not fluent in verilog. I prefer VHDL but not let start that thread again. When you use U_SET, every primitive within that SET as to have the attribute U_SET. You have to assign the U_SET attribute to all SRL16C and FD in the submodule. That's why I pass along the U_SET name as a generic in my VHDL code. When you use H_SET, all primitives within a module belong to the same SET but for U_SET for have to assign each primitive to the SET. I have attached a module from MicroBlaze which detect ZERO on one of the register values. Here you can see that I pass along a generic called C_U_SET which is of the type string. I use that value for the attribute value of U_SET. When I instanciate the module on a higher level, I assign a unique name to the generic or giving it a common name if it belongs to a bigger RPM. The actual values for the RLOC in this module is calculated in the function which exists in a library. That will allow me to handle all floorplanning in one place and also handle the difference of the RLOC values between "XnYm" and "RnCm.S" for different families. That a nice thing with VHDL. Göran >>>>>> insane quote removed by archive manager Martin Euredjian wrote: >This is the top module. It's simple. I'm using the new attribute syntax to >specify U_SETs. It's nice 'cause you can comment these out if you are >experimenting. > >code below. > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Martin Euredjian > >To send private email: >0_0_0_0_@pacbell.net >where >"0_0_0_0_" = "martineu" > > > > > >module test( > input wire clk, > input wire [9:0] a, > input wire [9:0] b, > output reg [10:0] total >); > >wire [9:0] a_dly[1:0]; > >(* U_SET = "DLY00" *) >SRL_DLY #(.WIDTH (10), .DELAY ( 2)) DLY00(.CLK(clk), .IN(a), >.Q_OUT(a_dly[0]), .Q15_OUT()); >(* U_SET = "DLY01" *) >SRL_DLY #(.WIDTH (10), .DELAY ( 4)) DLY01(.CLK(clk), .IN(a), >.Q_OUT(a_dly[1]), .Q15_OUT()); > >always @(posedge clk) begin > total <= a_dly[0] + a_dly[1]; >end > >endmodule > > > >Article: 61639
Hello, I want to implement a cache which has over 30 words á 2 bytes. The description of that module should be in VDHL. The problem I am facing right now is the following: It should be feasible to write an address into it and to read an address out of it. The most important function should be that a new incoming address should be checked if it is already in the cache. This check should occur within some few clocks. The problem is that the cache has over 30 entries so that using a FIFO or a RAM-structure would take over 30 clock cycles to check all the words. Has anyone an idea how this problem could be solved basically in order to achieve a faster check time? Thank you very much for your help. Kind regards Andrés Vázquez G&D System Development - FPGA designArticle: 61640
I always visualise what I want, not how I get there.. there's an old saying.. if you keep looking down you will never see the sky. Same with FPGA's.. if you keep looking at the gates, you miss the big picture.. VHDL and Verilog allow you to design high level. think concepts.. then thing solutions.. same as designing Top Down Software. Simon "Kevin Kilzer" <kkilzer.remove.this@mindspring.com> wrote in message news:qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com... > When you write VHDL (or Verilog for that matter), do you visualize a > schematic with wires, gates, flops, latches, muxes, etc., or do you > use some other way of thinking about it? > > Kevin >Article: 61641
the schematics are on the Altera web site. "Ben Popoola" <b.popoola@ntlworld.com> wrote in message news:oVMgb.20449$4D.10223328@newsfep2-win.server.ntli.net... > Hi, > Does anyone have a schematic for the Altera byteblaster II cable or > has anyone developed a programmer for programming the ALtera EPCS1/4 > family of serial configuration devices. > > I am designing a board and I want to design the programmer into the > system. > > Regards > Ben >Article: 61642
Have a talk to your friendly Xilinx Apps engineer Spartan 3's can tolerate a high jitter (So I've read) .. they just wont tell you that except under NDA. Simon "Ray Andraka" <ray@andraka.com> wrote in message news:3F8325DD.371B7949@andraka.com... > Nope, Jitter out of the video decoders is about 10x what is allowed by the > DLL/DCM. I posted earlier a solution that works fine for this, and is used in > a number of my customer's products. > > > > Simon Peacock wrote: > > > If you pick the right xilinx you could multiply the 27MHz up to 108MHz > > internally. Just use the internal PLL > > > > Simon > > > > "Guy Eschemann" <geschemann@yahoo.fr> wrote in message > > news:b9f16a5b.0310062304.4b75202a@posting.google.com... > > > > But you said that the clock was not truly asynchronous, but was 4 times > > > > the data rate, with an unknown ( but stable?) phase relationship. > > > > > > > > > > Maybe my description was a bit confusing, sorry for this. The clocks > > > really are asychronous. There is no stable phase relationship between > > > them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync > > > of a video signal, and the 108MHz system clock is derived from a 27MHz > > > crystal oscillator. > > -- > --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: 61643
You could always get it to flash a LED every few seconds :-) Simon "Emile" <banktrade2002@yahoo.com> wrote in message news:952209fb.0310070512.731ec498@posting.google.com... > Can someone suggest a project/application that would call for an > XC2V6000-4BF957C? Thanks. > > -EmileArticle: 61644
Synplify is suppose to be a better tool.. It should be at the price. Have you tried using the Synplify EDF output file as the quartus source file ? That way you get all the benefit of the synplify work. Simon "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message news:3F82F013.5000007@flukenetworks.com... > Bob wrote: > > > I re-synthesized the design again in Synplify and got the same result > > as before so there is definitely some problem in the flow between the > > two tools. It certainly looks like I'm back to the drawing board > > design wise. > > > > If you can think of anything else, I would be very grateful. > > Maybe you can eliminate the flow between the tools. > Try bypassing Synplify and process your source files > directly with Quartus synthesis. > > -- Mike Treseler >Article: 61645
"Vazquez" <andres.vazquez@gmx.de> wrote in message news:eee19a7a.0310080131.5a53d3f2@posting.google.com... > Hello, > > I want to implement a cache which has over 30 words á 2 bytes. > The description of that module should be in VDHL. > > The problem I am facing right now is the following: > > It should be feasible to write an address into it and to read an > address out of it. > The most important function should be that a new incoming address > should be > checked if it is already in the cache. This check should occur within > some few clocks. The problem is that the cache has over 30 entries so > that > using a FIFO or a RAM-structure would take over 30 clock cycles to > check all the > words. > > Has anyone an idea how this problem could be solved basically in order > to achieve a faster check time? > > Thank you very much for your help. > > Kind regards > Andrés Vázquez > G&D System Development - FPGA design http://www.altera.com/support/software/eda_quartus2/glossary/def_cam.html Gr, HansArticle: 61646
There was an error in the code posted below. I posted the wrong iteration of code. The error had nothing to do with the problem (but didn't help). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:axGgb.12589$g_2.8245@newssvr25.news.prodigy.com... > This is the module with the RLOCs. > I'm just hacking away here, so it's not perfect code. > The long list of RLOC/BEL attributes is there because I haven't been able to > figure out how to integrate that into the "generate" portion of the code. I > don't see a way to construct the attribute string --even with the V2001 > (*...*) attribute format. Yet another case for VHDL :-( > > Code below. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > > > > > // Generates an SRL-based shift register of the desired word width and delay > (in clocks) > // A minimum delay of 2 clocks is required, as the output is registered. > // "Q15_OUT" is the cascading SRL output, used to get 16 clocks of delay, > regardless > // of the DELAY setting. > // > > module SRL_DLY > #(parameter WIDTH = 8, DELAY = 2) > ( > input wire CLK, > input wire [WIDTH - 1:0] IN, > output wire [WIDTH - 1:0] Q_OUT, > output wire [WIDTH - 1:0] Q15_OUT > ); > > localparam D = DELAY - 2; > > wire [WIDTH - 1:0] qw; > > genvar i; > > generate > for(i=0; i < WIDTH; i=i+1) begin:BIT > SRLC16 SRL(.Q(qw[i]), .Q15(Q15_OUT[i]), .A3(D[3]), .A2(D[2]), .A1(D[1]), > .A0(D[0]), .CLK(CLK), .D(IN[i])); > FD DFF (.Q (Q_OUT[i]), .C (CLK), .D (qw[i])); > end > endgenerate > > // RLOC the SRLC16 primitives > // > //synthesis attribute RLOC of BIT[0].SRL is X0Y0 > //synthesis attribute BEL of BIT[0].SRL is F > //synthesis attribute RLOC of BIT[1].SRL is X0Y0 > //synthesis attribute BEL of BIT[1].SRL is G > > //synthesis attribute RLOC of BIT[2].SRL is X0Y1 > //synthesis attribute BEL of BIT[2].SRL is F > //synthesis attribute RLOC of BIT[3].SRL is X0Y1 > //synthesis attribute BEL of BIT[3].SRL is G > > //synthesis attribute RLOC of BIT[4].SRL is X0Y2 > //synthesis attribute BEL of BIT[4].SRL is F > //synthesis attribute RLOC of BIT[5].SRL is X0Y2 > //synthesis attribute BEL of BIT[5].SRL is G > > //synthesis attribute RLOC of BIT[6].SRL is X0Y3 > //synthesis attribute BEL of BIT[6].SRL is F > //synthesis attribute RLOC of BIT[7].SRL is X0Y3 > //synthesis attribute BEL of BIT[7].SRL is G > > //synthesis attribute RLOC of BIT[8].SRL is X0Y4 > //synthesis attribute BEL of BIT[8].SRL is F > //synthesis attribute RLOC of BIT[9].SRL is X0Y4 > //synthesis attribute BEL of BIT[9].SRL is G > > //synthesis attribute RLOC of BIT[10].SRL is X0Y5 > //synthesis attribute BEL of BIT[10].SRL is F > //synthesis attribute RLOC of BIT[11].SRL is X0Y5 > //synthesis attribute BEL of BIT[11].SRL is G > > //synthesis attribute RLOC of BIT[12].SRL is X0Y6 > //synthesis attribute BEL of BIT[12].SRL is F > //synthesis attribute RLOC of BIT[13].SRL is X0Y6 > //synthesis attribute BEL of BIT[13].SRL is G > > //synthesis attribute RLOC of BIT[14].SRL is X0Y7 > //synthesis attribute BEL of BIT[14].SRL is F > //synthesis attribute RLOC of BIT[15].SRL is X0Y7 > //synthesis attribute BEL of BIT[15].SRL is G > > > // RLOC the FF's > // > //synthesis attribute RLOC of DFF[0] is X0Y0 > //synthesis attribute BEL of DFF[0] is FFX > //synthesis attribute RLOC of DFF[1] is X0Y0 > //synthesis attribute BEL of DFF[1] is FFY > > //synthesis attribute RLOC of DFF[2] is X0Y1 > //synthesis attribute BEL of DFF[2] is FFX > //synthesis attribute RLOC of DFF[3] is X0Y1 > //synthesis attribute BEL of DFF[3] is FFY > > //synthesis attribute RLOC of DFF[4] is X0Y2 > //synthesis attribute BEL of DFF[4] is FFX > //synthesis attribute RLOC of DFF[5] is X0Y2 > //synthesis attribute BEL of DFF[5] is FFY > > //synthesis attribute RLOC of DFF[6] is X0Y3 > //synthesis attribute BEL of DFF[6] is FFX > //synthesis attribute RLOC of DFF[7] is X0Y3 > //synthesis attribute BEL of DFF[7] is FFY > > //synthesis attribute RLOC of DFF[8] is X0Y4 > //synthesis attribute BEL of DFF[8] is FFX > //synthesis attribute RLOC of DFF[9] is X0Y4 > //synthesis attribute BEL of DFF[9] is FFY > > //synthesis attribute RLOC of DFF[10] is X0Y5 > //synthesis attribute BEL of DFF[10] is FFX > //synthesis attribute RLOC of DFF[11] is X0Y5 > //synthesis attribute BEL of DFF[11] is FFY > > //synthesis attribute RLOC of DFF[12] is X0Y6 > //synthesis attribute BEL of DFF[12] is FFX > //synthesis attribute RLOC of DFF[13] is X0Y6 > //synthesis attribute BEL of DFF[13] is FFY > > //synthesis attribute RLOC of DFF[14] is X0Y7 > //synthesis attribute BEL of DFF[14] is FFX > //synthesis attribute RLOC of DFF[15] is X0Y7 > //synthesis attribute BEL of DFF[15] is FFY > > > endmodule > >Article: 61647
> Comparing 5.2 with 6.1, we have found that 5.2 said > --------------------------------------------------- > LPT base address = 0378h. > --------------------------------------------------- > > but 6.1 says > --------------------------------------------------- > LPT base address = 0B78h. > --------------------------------------------------- Hi all, again, Neil from Xilinx assisted us offline to better diagnose this problem, and in the process of answering his questions it came out that another, identical PC in our department was able to run the software perfectly. Identical since they were bought at once, same store, same model, same date. Basically identical SiSoft SANDRA listings. So, whatever the problem is, it's a problem with that particular PC, be it hardware, BIOS, XP configuration... In short: we have found a PC with such a subtle configuration or hardware failure that it fools iMPACT 6.1 making it believe that LPT1: is at 0B78 (I love reproducible errors :-) We'll try to interchange that computer with somebody else's and upgrade to 6.1 then. Thanks to all again -javierArticle: 61648
On Tue, 07 Oct 2003 19:39:11 -0400, Ray Andraka <ray@andraka.com>
wrote:
>BTW, this is a heckuva lot easier in VHDL with the generate statements. With
>VHDL you can convert the generate index variable to a string constant to form
>the attribute string. I don't know of a way to do that in verilog. For VHDL,
>the code might look like:
>
>L:for i in 0 to width-1 generate
> constant rloc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" &
>itoa(slice mod 2);
> signal l,d,qr,qs: STD_LOGIC;
> attribute BEL of U1:label is bel_lut(i mod 2);
> attribute RLOC of U1 : label is rloc_str;
Hi Ray,
I've been using Verilog recently. Verilog got a whole lot better
(read: borrowed some features from VHDL) with the 2001 language
revision.
Pertinent bits added:
new attribute syntax.
generate statements.
constant functions (i.e. functions that can run at elaboration time).
$swrite system task.
It would seem that the above VHDL fragment could be translated to
Verilog as follows:
genvar i;
generate
for (i = 0; i < width; i=i+1)
begin
(* RLOC = $swrite("R%dC0.S", origin -(i/2)) *)
(* BEL = i%2 ? "G" : "F" *)
// instantiate something here
end
end generate
But there are still problems:
1. $swrite is a system task, and system tasks can't be used in
constant functions.
2. The (* name = value *) attribute syntax doesn't seem to allow
anything other than integer values. I don't have the Verilog 2001
LRM, so I can't say for sure.
This current comp.lang.verilog thread gives some hints:
http://groups.google.com/groups?threadm=3a8e124e.0310071017.75124189%40posting.google.com
3. This is all new to the Verilog language. Good tool support isn't
there yet. The equivalent features have been in VHDL since the '87
version, so the VHDL tool support is a lot better.
Note: XST 6.1 supports the new attributes but the value must be a
string literal, i.e. it's useless for this sort of work.
It looks like I'll have to wait another few years. Sigh.
Regards,
Allan.
Article: 61649"Vazquez" <andres.vazquez@gmx.de> wrote in message news:eee19a7a.0310080131.5a53d3f2@posting.google.com... > I want to implement a cache which has over 30 words á 2 bytes. > It should be feasible to write an address into it and to read an > address out of it. > The most important function should be that a new incoming address > should be > checked if it is already in the cache. This check should occur within > some few clocks. The problem is that the cache has over 30 entries so > that using a FIFO or a RAM-structure would take over 30 clock > cycles to check all the words. > > Has anyone an idea how this problem could be solved basically in order > to achieve a faster check time? The usual arrangement in caches is to compute some function of the address, and use that as the index into your cache. That way, it's very easy to locate whether an address is held in the cache. Typically the "function" is just the bottom few bits of the address, because this gives a reasonable distribution of cached addresses into cached locations for many practical problems. I don't know how big your addresses are, but let's guess they are 16 bits wide. Let's also suppose that you use the bottom 5 bits of address to index into your 32-slot cache. Now let's suppose you have accessed some locations... 0x1234 -- uses cache slot 0x14 0x1235 -- uses cache slot 0x15 0x9A23 -- uses cache slot 0x03 You can see that this scheme will work well for short sequential burst accesses. However, let's now suppose that you make a fourth access... 0x7255 -- uses cache slot 0x15 This new access will of course evict the 0x1235 entry from slot 0x15. To make all this work, each cache slot needs to store... * those bits of the address that were not used to index it: in my example, the top 11 bits * the cached data * a "valid" bit, to say that the stored data is correct * (for write-back caches) a "dirty" bit, saying that the cache slot has been written with a new data value, but the cached memory location hasn't yet been written with this new value To improve performance, caches can have N-way associativity - in other words, you have more than one cache slot associated with each cache index. This means you have to compare addresses, but typically only 2 or 4 rather than the full 32. You can generally do this with parallel, single-cycle logic. If indexing on the bottom few bits of address doesn't suit your requirement, you can use a more sophisticated address mapping - perhaps some kind of hash function. It doesn't matter, as long as the function is repeatable and distributes addresses onto cache slots in a suitable way. You would then need to store the whole address in the cache. -- 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, Hampshire, 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.
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