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
Kolja Sulimma <kolja@sulimma.de> writes: > Austin Franklin wrote: > > > The PCI core itself, as far as PCI accessibility, is really only > > configuration space. I don't believe there's really anything to access > > there for a "driver"... If you mean access the resources that are behind > > the BARs etc. of course, that makes sense...but there isn't anything in the > > core it self that requires a driver, per se, I don't believe, and they would > > be particular to the application the back end is designed for, not the core. > > > > I don't understand what would be particular to "the PCI core", as opposed to > > any PCI device...the real particulars for a driver are what's in the memory > > and I/O space, and that's outside the core. > Ahh. At least you need a driver to find out to what address your PCI > device was mapped. This would pretty much concern the core. No, it concerns the result of the PCi-discover routine, which is not deopendant upon the PCI core, but a part of the main OS, and dependent on the main PCI board. > Also you would like to enable and disble memory ranges, See above. > enable interupts, burst > mode, .... > Core functions too. Is there interrupts in the Xilinx PCI core? Interrupts tend to be system dependent. > When all this is done, all there is left to do to access you card is to map the > memory ranges to user space. > (Ooops, another core related function) Not done by any driver. See above. Depends on what you mean by a driver. You need SW for the above tasks, but finding out the memory range, mapping and so on is not dependant on the PCI card/core, but of the OS on the main board. > After that, you can start using the functionality that you connected to the > core. Sure. But the above tasks does not require a driver. The core is a part of a complete PCI function, and there is no point in writing a driver for it, as it cannot do anything useful by itself. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 31676
I do not know to much about driver development outside a Linux system. Therefore your information could be very helpful for me. (My customers just won't switch to Linux, damn) > > Ahh. At least you need a driver to find out to what address your PCI > > device was mapped. This would pretty much concern the core. > > No, it concerns the result of the PCi-discover routine, which is not > deopendant upon the PCI core, but a part of the main OS, and dependent > on the main PCI board. What you are saying is, that I can write a user mode programm without the use of a DDK to ask where my board was mapped? Let's say with win2k, winNT, ... > > Also you would like to enable and disble memory ranges, > > See above. > > > enable interupts, burst > > mode, .... > > Core functions too. > > Is there interrupts in the Xilinx PCI core? Interrupts tend to be > system dependent. They are part of the PCI standard as far as the core is concerned.(Section 2.2.6) The handling, routing, etc. of the interupt are system dependant, but the core could not care less. > > When all this is done, all there is left to do to access you card is to map the > > memory ranges to user space. > > (Ooops, another core related function) > > Not done by any driver. See above. Again: I really, really would like to do this from a user mode program without a driver. Please tell me how. > Depends on what you mean by a driver. You need SW for the above tasks, > but finding out the memory range, mapping and so on is not dependant > on the PCI card/core, but of the OS on the main board. That is right. It will be the same problem for any kind of card regardless of functionality. But it needs to be done, and as far as I know it is usually done within the driver. > The core is a part of a complete PCI function, and there is no point > in writing a driver for it, as it cannot do anything useful by itself. But know it will take me a week to figure out how to map my memory ranges to user space under win2k. If you give me source code for that I will implement the functionality in an hour or two. Therefore from my point of view, the above functions are 90% of the driver. (Remember, I am not talking about directX8 drivers, but about something as parallel port cards, 4 channel data aquistion circuits, and so on. The driver functionality is close to NIL) Kolja SulimmaArticle: 31677
Austin Franklin wrote:
>
> > > > Simple question!
> > > >
> > > > My design simulates with modelsim and fits OK with webpack.
> > > >
> > > > My question is how do I re-import my design into modelsim to check it
> > > still
> > > > works?
> > > >
> > > > Cheers
> > > > Dave
> > >
> > > Why would you want to do that?
> > >
> > > There should be no need for timed stand-alone simulations provided you
> used
> > > TIMESPECs, and your TIMESPECs are accurate.
> >
> > ... and the tools don't have bugs.
> >
> > ... and the speed files accurately reflect the operation of the silicon.
> >
> > Bitten by both on my last project. Ouch.
> >
> > In the speed file case, a gate level simulation won't help, as the back
> > annotated VHDL (or Verilog, etc.) will have the values from the speed
> > files, not the values from the silicon. The only way to catch these is
> > to try them in the lab, over temperature and voltage variations.
> >
> > The gate level simulation was useful for picking up some of the tool
> > bugs. Others bugs were more amenable to inspections using FPGA Editor,
> > or netlist browsing.
Hi Austin,
> Please name the tools and tool bugs you found doing timed simulations, as
> well as the bugs you found using FPGA editor. I know MANY designers who do
> exactly as I stated and have never had a problem.
You do test your designs, don't you? ;-)
Offhand, I can't think of a project I've worked on recently where I
*haven't* found an undocumented tool bug. Mostly they are minor things
though.
Using *untimed* gate level simulations, I only found one serious tool
bug in my last project, in Synplify 6.0.0. It was getting the initial
state of flip flops wrong.
In VHDL:
process(clk, gsr)
begin
if gsr = '1' then
ff <= '1';
elsif rising_edge(clk) then
ff <= something else;
end if;
end process;
Synplify would recognise that the async reset on the ff was actually the
Xilinx GSR net, so it wouldn't bother to explicitly put the reset info
in the EDIF output, and so the fact that the reset state was '1' (and
not the default '0') was lost.
I believe that this has been fixed in more recent versions. It took
some weeks to get Synplify support to understand this problem, even when
it was expressed in very simple terms.
Another favourite (not in Synplify) was this assignment to a top level
output port:
x <= 'Z';
You would think that this would make the output tristate. Instead, it
turned into:
x <= '0';
That synthesis tool (which shall remain nameless) has also been fixed,
and now generates the correct code.
These bugs were found by running the back annotated gate level VHDL
through my regular VHDL test bench for the chip. The test bench would
tell me that there was a problem. Then I needed FPGA editor to work out
where the problem was in the chip (although the gate level VHDL source
and a text editor would have been just as good, if a little cumbersome).
> If you do a back annotated simulation, you do not have to run this as a
> timed simulation, you can still do it as unit delay.
Yes, this is the way I normally do them. I'm a big believer in
functional simulation and static timing analysis. (Although care is
needed to ensure the correctness of multicycle paths.)
I should point out that I don't normally do gate level simulation,
except when I suspect that there is a tool problem.
> As you said, the speedfile issue is a non-issue, simply because you are
> using the speedfiles TO generate the timing information for the back
> annotated simulation. So, why even bring that up?
I wanted to point out that there are limitations of timed, gate level
simulations.
I should have also brought up silicon bugs (again, bitten on my last
project) as another example of something that can't be found in a gate
level simulation.
Regards,
Allan.
Article: 31678Kolja Sulimma <kolja@sulimma.de> writes: > > > Ahh. At least you need a driver to find out to what address your PCI > > > device was mapped. This would pretty much concern the core. > > > > No, it concerns the result of the PCi-discover routine, which is not > > deopendant upon the PCI core, but a part of the main OS, and dependent > > on the main PCI board. > > What you are saying is, that I can write a user mode programm > without the use of a DDK to ask where my board was mapped? Let's say > with win2k, winNT, ... No, what I'm saying is that it's the responsibility of the OS to discover and map the PCI boards, and then call the vendor supplied - board specific! - driver. If your board can't do anything, there is no point in having a driver. What you need is an OS specific development toolkit. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 31679
> Hi Austin, > > > Please name the tools and tool bugs you found doing timed simulations, as > > well as the bugs you found using FPGA editor. I know MANY designers who do > > exactly as I stated and have never had a problem. > > You do test your designs, don't you? ;-) Naw, we just throw them over the wall and tell them if it doesn't work, it must be software. > > If you do a back annotated simulation, you do not have to run this as a > > timed simulation, you can still do it as unit delay. > > Yes, this is the way I normally do them. I'm a big believer in > functional simulation and static timing analysis. Er, then what's the fuss? > (Although care is > needed to ensure the correctness of multicycle paths.) Why? > I should point out that I don't normally do gate level simulation, > except when I suspect that there is a tool problem. I have not run into the problems you cited, but I don't use VHDL...ever think that might be the problem ;-) You are right, that certainly is an acceptable "excuse" for doing back annotated simulations...but, given your lead, they would be equally, if not more, error prone. I found more bugs in the back annotation tools than in the front end tools.Article: 31680
Mike wrote: > Bitstream compression uses something called MultiFrame writes. This means that if two (or more) configuration frames have the > same data, they can all be written with one command. Do you know what the file format is? I am currently reading .bit files, but I would like to save a few bytes (to reduce disk space and file transfer time) Alan Nishioka alann@accom.comArticle: 31681
No, I didn't find on Zilog.com, I think Zilog doesn't provide open microprocessor core any different idea where I can get core fore Z180 or Z182 Thanks Iouri CBFalconer wrote: > Iouri Besperstov wrote: > > > > CBFalconer wrote: > > > > > Richard Erlacher wrote: > > > > > > > > On Tue, 29 May 2001 13:06:57 GMT, "Mark Walter" <maw@nospam.com> > > > > wrote: > > > > > > > > >It appears that the tools for the SFL language support conversion to Verilog > > > > >or VHDL. Is it possible someone can convert this 8080 processor core into > > > > >Verilog or VHDL. Then it could be used with the Xilinx tools for creating a > > > > >8080 clone... > > > > > > > > Since there are still V40 and V50 devices available, albeit with some > > > > difficulty, but at a small fraction of the cost of a major FPGA, it > > > > might be well to examine one of those processors for use of its > > > > built-in 8080 core. You can, if you like, use the 8086-compatible > > > > instruction set to execute what will probably have to be an original > > > > BIOS, yet use the internal 8080 to execute the CP/M code. Of course > > > > it's not Z-80 compatible, but who cares? > > > > > > That only makes sense if you want the 8086 instruction set also. > > > Otherwise why not just use a Z180? All Z80's execute the 8080 > > > instruction set, with the exception being some parity bit > > > settings, and nobody in their right mind ever wrote code that ran > > > into that after the first z80's came out. > > > > How or where I can get Z180 or Z182 core??? > > Try zilog. http://www.zilog.com Or almost any distributor. > > -- > Chuck F (cbfalconer@my-deja.com) (cbfalconer@XXXXworldnet.att.net) > http://www.qwikpages.com/backstreets/cbfalconer :=(down for now) > (Remove "NOSPAM." from reply address. my-deja works unmodified) > mailto:uce@ftc.gov (for spambots to harvest)Article: 31682
Ben wrote:
> It is very interesting that they have a special cell for synchrnonizers
> though I don't find any special cell in my ASIC library.
that may well be true not every library has one - usually you would map the
cells you know are synchronisers to the special cell in your library and
mark it dont_touch (tm :-) so that it doesn;t get remapped to something else
> Fortunately, I could just avoid this timing error during verilog prelayout
> simulation by using characteristics of the two clocks.
> One clock domain of my design was synthesized barely fit into 30ns (33MHz
> PCI clock) and the other was 40 ns.
> Thus if I use two clocks of period 30ns and 40ns each, and make the
> initial rising edge of each clock to coincide, then I have 10ns margin for
> any neighboring rising edge of the two clocks.
> This blew out my agony.
be VERY carefull - in real life those edges wont perfectly overlap - if
anything you need to toss some clock skew in the mix. Of course you are
using this trick to avoid the setup/hold issues on the clock domain
crossing paths - but what happens if there are other paths you are unaware
of? my personal preference to to declare false paths on only the paths that
I've determined to be synchronised (ie have synchronisers etc etc) and set
up the rest so that any unknown paths jump out with timing errors so that I
can pay attention to them.
Because you are using DW you are kind of forced to work with mutiple clocks
- I have found that a better design style for multiple clock domain work is
to write each clock domain seperately, each in its own hierarchy (you
should probably put domains that synchronous wrt each other together) and
then create a top level verilog module that brings the clock domains
together - that way any wires that go between modules at this top level are
by definition domain crossing and should be synchronised. The other great
thing about this way of doing things is that you can synthesise each of the
sub-blocks with a single clock (synopsys runs faster!) and resolve all the
timing issues there - when you've synthesised the sub modules you then read
them into synopsys along with the top level verilog, ungroup them then
write the result out (without compiling) this gives you the netlist with
all the clock domains in it but without any timing having been done between
them (after all by definition there is no timing between asynchronous
domains)
Paul
Article: 31683I've been poking around the Xilinx website trying to find a URL from which I can order the Webpack ISE cdrom. So far no joy. Does anyone know the exact Xilinx url for ordering the Webpack ISE CDROM? Thanks, Dave FeustelArticle: 31684
Dave Feustel wrote: > > I've been poking around the Xilinx website trying to find a > URL from which I can order the Webpack ISE cdrom. > So far no joy. > > Does anyone know the exact Xilinx url for ordering the Webpack > ISE CDROM? If you get no joy, I can send you the one that came free with my Burch kit. It's only a 'cd single' size, but I think it's got everything on it. (I had already d/l'd all the software :-) ATB, Simon. -- Freedom ? What's that ? (see http://www.domesday.co.uk/ )Article: 31685
I now have the Open Tech 1.1.0 CDROM set Can any of the tools on this cdrom set generate FPGA configuration bitstreamss for Atmel Parts? (Particularly the Atmel FPSLIC) How about for Xilinx parts (Spartan-2, Virtex)? Which parts (Atmel, Xilinx, other) are best for implementing open cores? Thanks, dfArticle: 31686
What is the FPGA kit? "Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message news:3B1439AE.D684F26@jetnet.ab.ca... > Simon wrote: > > If you get no joy, I can send you the one that came free > > with my Burch kit. It's only a 'cd single' size, but I > > think it's got everything on it. (I had already d/l'd all > > the software :-) > > Hmm another good point for the FPGA kit!Article: 31687
We have some excess materials left over from a project. This includes some remaning parts to program QuickLogic devices. Please visit and make offer at: http://www.jumboprawn.net/forsale/ql_100144.html http://www.jumboprawn.net/forsale/ql_base.htmlArticle: 31688
Alan, The decompression is done at the hardware level. Virtex bitstreams are really just a sequence of reads and writes to registers- it's a very processor-like interface. When a compression bitstream is created, this file just has some different commands in it. It's not compression like zip or tar compression (software level compression/decompression). The bit file will be the smallest file you can get for configuration. MikeArticle: 31689
Hi Pete, This looks more like a library error than a VSM/Viewbase error. Can you send me a design fragment that has this problem, including the viewdraw.ini file, and tell me which version of the viewdraw libraries you are using, and which instalation kit they came from. Hope to help, Philip Freidin On Fri, 1 Jun 2001 13:09:04 -0600, "Pete Dudley" <padudle@sandia.gov> wrote: >Hello All, >I have just encountered a problem simulating my Viewdraw schematics that >contain VirtexII flip flop symbols. It appears that the viewdraw symbols use >the @INIT parameterized attributes to control the initial state of flip >flops but the simulation netlister VSM does not parse them correctly. I get >the following error from VSM. > >ER Error: viewbase: Error 338: Undefined variable(s) encountered >(FLOATVAL=@INIT). >| Occurred on net instance $1I1\$1I15\GSR_INIT0 >I realize that it is unfashionable to use schematic entry but I have some >large blocks of IP that I want to carry forward from an old Virtex design. >If anyone knows a workaround for this one I would appreciate a hint. > >Thanks, =================== Philip Freidin philip@fliptronics.com Host for WWW.FPGA-FAQ.COMArticle: 31690
There are some not-so-obvious advantages, e.g. use of ISA-board-resident EPROM code to operate an ISA card in lieu of building a replacement for a common ISA circuit, e.g. a SCSI adapter, or the like. building an ISA adapter to a V40/V50 is dirt simple. Using adapter-resident ROM code requires, of course, that you know how to use that code, but given that it's not a secret ... The other thing is that you can, at your option, run CP/M-86 as well. The V50, for example has a 16-bit bus and makes IDE interfacing quite simple. Moreover, development tools for the 8086 instruction set are in everybody's hands these days, while Z180/Z280, or ARM tools are not. I'd suspect that a 16 MHz V50, which has serial I/O, DMA, interrupt, and counter/timer logic on board, would be pretty fast, too. It's just a thought, after all. Using an 8086-code BIOS is not a bad idea, though. Dick On Fri, 01 Jun 2001 04:34:01 GMT, CBFalconer <cbfalconer@my-deja.com> wrote: >Richard Erlacher wrote: >> >> On Tue, 29 May 2001 13:06:57 GMT, "Mark Walter" <maw@nospam.com> >> wrote: >> >> >It appears that the tools for the SFL language support conversion to Verilog >> >or VHDL. Is it possible someone can convert this 8080 processor core into >> >Verilog or VHDL. Then it could be used with the Xilinx tools for creating a >> >8080 clone... >> >> Since there are still V40 and V50 devices available, albeit with some >> difficulty, but at a small fraction of the cost of a major FPGA, it >> might be well to examine one of those processors for use of its >> built-in 8080 core. You can, if you like, use the 8086-compatible >> instruction set to execute what will probably have to be an original >> BIOS, yet use the internal 8080 to execute the CP/M code. Of course >> it's not Z-80 compatible, but who cares? > >That only makes sense if you want the 8086 instruction set also. >Otherwise why not just use a Z180? All Z80's execute the 8080 >instruction set, with the exception being some parity bit >settings, and nobody in their right mind ever wrote code that ran >into that after the first z80's came out. > >-- >Chuck F (cbfalconer@my-deja.com) (cbfalconer@XXXXworldnet.att.net) >http://www.qwikpages.com/backstreets/cbfalconer :=(down for now) > (Remove "NOSPAM." from reply address. my-deja works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) > >Article: 31691
Mike wrote: > The decompression is done at the hardware level. Virtex > bitstreams are really just a sequence of reads and writes to > registers- it's a very processor-like interface. When a compression > bitstream is created, this file just has some different commands in it. It's not compression like zip or tar compression (software level > compression/decompression). The bit file will be the smallest > file you can get for configuration. I assumed that compression meant software compression, so I didn't even try it. Now that I try it, it works fine. It saves me about 10 percent. Thank you very much for your help Alan Nishioka alann@accom.comArticle: 31692
I've been using system Generator for three months since it's release and have found somewhat erratic performance. I would be interested in sharing my experience with other System Generator users in hopes of finding and sharing solutions that would be of benefit to all. Perhaps a data base could be constructed outside the Xilinx infrastructure for this purpose. Regards,Article: 31693
> > > > Ahh. At least you need a driver to find out to what address your PCI > > > > device was mapped. This would pretty much concern the core. > > > > > > No, it concerns the result of the PCi-discover routine, which is not > > > deopendant upon the PCI core, but a part of the main OS, and dependent > > > on the main PCI board. > > > > What you are saying is, that I can write a user mode programm > > without the use of a DDK to ask where my board was mapped? Let's say > > with win2k, winNT, ... > > No, what I'm saying is that it's the responsibility of the OS to > discover and map the PCI boards, and then call the vendor supplied - > board specific! - driver. > > If your board can't do anything, there is no point in having a driver. > > What you need is an OS specific development toolkit. > > Homann Thank you, of course, for chiming in. My other point was that a driver is NOT PCI "core" dependant. Whether you use the Xilinx PCI core, or any other core that provides PCI configuration, and target/master function support, the driver will not be different...if the back end is the same.Article: 31694
Hi I suggest the following: 1. Use special names for the synchronized FF. Special means something to be easily found with a PERL/c-shell/... in the SDF file. 2. Write a PERL scripts that looks in the SDF file for the offending FF devices. Set the setup check off. "Ben" <ejhong@future.co.kr> wrote in message news:<3VkR6.218$by4.4024@news2.bora.net>... > Hi, > > I use two independent clocks and an asynchronous fifo from synopsys > DesignWare in my design. > This means there is frequent data transfer between the clock domains. > During the simulation, a fliflop which gets signal from another flipflop of > different clock domain generated setup time violation error. > The flipflop must be some kind of synchronizer for internal control of fifo. > I think this kind of error is ubiquitous for 2-clock design or any design > that has synchronizer for asynchronus signal in it, and believe that there > is some technique which will prevent or bypass timing error during > simulation. > Please help me out of this problem. > > Thanks, > > BenArticle: 31695
pini wrote: > Hi > I suggest the following: > 1. Use special names for the synchronized FF. Special means something to be > easily found with a PERL/c-shell/... in the SDF file. > 2. Write a PERL scripts that looks in the SDF file for the offending FF devices. > Set the setup check off. > > I personally feel that a metastab error can ruin your day so badly that you should *not* disable them in simulation. To this end I've generated modified versions of the Xilinx X_FF & X_SFF simprims primitives that: o Set the output to `X' for a - parametrizable - period of time after a su/hld violation. o Then randomly set the output to 0 or 1. I then use the tricks 1 & 2 + a perl script to change the instantiations of the synchronisers to the hacked version. I'll put the stuff on our FTP if anyone's interested. Note that using 1. above also makes it easy to pick out the synchronisers in the .ucf file & apply special timing constraints.Article: 31696
Who can help me ? Is it right, that the PCI Configuratins Register Space of an PCI - Device access with a Config Adress Register (0CF8h) and Config Data on =CFAh ? How can i use this register, and what have done this with the Configurations Register Space ? Thanks! MarioArticle: 31697
Michael Dales <michael@dcs.gla.ac.uk> writes:
> I'm trying to implement an algorithm using the LUT4 on Virtex. I have
> numerous variations on the following:
>
> lut_0: LUT4 generic map (INIT => X"0E6E")
> port map (res(0), val(0), val(1), val(2), val(3));
>
> This simulated fine using the Alliance libraries compiled for Cadence
> Leapfrog, but when I tried to run it through FPGA Express it barfs on
> my generic map, with the following error:
>
> "Bad formal part - port names in entity and component declarations do
> not match."
>
> I checked the unisim vcomponents file and the component declaration
> seems to be correct.
Hi, Michael.
I would suggest posting more of your VHDL code here, especially the
component declaration, since that's where you got the error.
My guess is that you didn't include the INIT generic in the declaration?
You might also try explicitly naming on all the ports in your port map.
(Shouldn't make a difference, but it looks clearer to those of us trying
to figure out what you're doing.)
For example:
lut_0: LUT4 generic map (INIT => X"0E6E")
port map (O =>res(0), I0=>val(0), I1=>val(1), I2=>val(2), I3=>val(3));
Hope this helps,
-Kent
Article: 31698
hello,
i can't find the clue on how to solve optimally this problem in
vhdl,(or verilog), any help please!!!
i want to design an irregular counter
say acound modulo 8 but with these outputs
[4,7,2,3,0,1,6,5]
someone suggests me to design a counter and later add such similair
code
CASE counter IS
WHEN 0 => output <= 4;
WHEN 1 => output <= 7;
.....
i expect that the synthesizer will do it in 2 logic levels, whereas
one logic level is feasible ?
thanks
Article: 31699Wisut Hantanong wrote: > I mean of pub license like some linux software or demo or shareware. > > thank you. There is no freeware that supports the XC4000E family. You can buy the Xilinx Student Edition 2.1i for $55 and it supports the smaller devices up to the XC4013. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||
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