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
Hi,
I'm not a software/C expert but I think you need to define your struct as
being volatile. Look at the following code example from the NIOS UART
driver.
// UART Registers
typedef volatile struct
{
int np_uartrxdata; // Read-only, 8-bit
int np_uarttxdata; // Write-only, 8-bit
int np_uartstatus; // Read-only, 8-bit
int np_uartcontrol; // Read/Write, 9-bit
int np_uartdivisor; // Read/Write, 16-bit, optional
int np_uartendofpacket; // Read/Write, end-of-packet character
} np_uart;
Hope this helps
Wolfgang
http://www.elca.de
"Stéphane Mancini" <stephane.mancini@inpg.fr> schrieb im Newsbeitrag
news:pan.2002.07.18.16.00.23.496256.3019@inpg.fr...
> Hi,
> I had a trouble with programming NIOS ISR.
> More precisely, I tried to synchronise a hardware device
> with software using ISR.
> That for, I used a software which is made of three pieces :
> - a context
> stores the context of hardware in a software point of view
> - an ISR
> modifies the context each time the hardware emit an IRQ
> - an API
> communicate to hardware and eventually locks until
> the context allows it.
>
> I used the following code in the API
>
> char read_data(...)
> {
> ...
> while (context->ready==0);
> ...
> }
>
> But it doesn't work because the compiler generates
> a code that causes the read of context->ready to
> be read from memory only once. The boolean equation
> is then evaluated but context->ready is not actualised.
> So, even if the ISR modifies the variable context->ready,
> it stills keep locks.
>
> Note : I saw his phenomenom thanks to modelsim simulation...
>
> I had to do :
>
> char is_ready(void)
> {
> return context->ready;
> }
>
>
> char read_data(...)
> {
> ...
>
> while (is_ready()==0)
> ...
>
> }
>
> This works fine but is a little bit heavy. The produced code is quit
> big and introduces an hoverhead.
>
> So, does anybody knows how to manage this ? How to force the real read of
the
> variable used for the lock ?
>
> Note : in a future version, the lock would be replaced by an OS
> semaphore...
>
>
> Thanks a lot for your responses.
>
> Stephane Mancini
Article: 45301Hi, I think XST doesn't support this directive, see: http://www.opencores.org/forums/pci/2002/04/00057 http://www.opencores.org/forums/cores/2002/03/00137 As a solution you might want to try V2K from: http://www.azuresys.com/p2.html Good Luck. Srinivasan -- Srinivasan Venkataramanan ASIC Design Engineer Software & Silicon Systems India Pvt Ltd. - an Intel company Bangalore, India I don't speak for Intel "BROTO Laurent" <lbroto@free.fr> wrote in message news:3d366d05$0$451$626a54ce@news.free.fr... > Hi all, > > I've downloaded the OpenCore's PCI IP Core. > I'm working with WebPack 4.2.03 and I've got problem when I want synthetize > the project. > > XST (the compiler) doesn't understand the `undef directive. > When I remove this directive, I've got multisource in signal xyz. > > Therefore, I've downloaded WebPack 3.8 to have the "Resolution Style" > option. > With this version, I can begin to compile the PCI Bridge, but 12 hours after > beginning, it's no yet finish. > > So, do you know how can I should synthetize this project ? > > Thanks a lot, > > Laurent > >Article: 45302
You can route your design manually and control every single bit if you use the Xilinx " FPGA editor". You need detailed kwnowledge of the FPGA internal architecture to do so. ... but this was done many years ago. Today you describe your design in a "high level" language like VHDL and let the tools map, place and route everything. The design editor is still useful to check the results. -Manfred "Mike Rosing" <rosing@neurophys.wisc.edu> schrieb im Newsbeitrag news:3D2AF452.6080800@neurophys.wisc.edu... > Howdy folks, > > I'm trying to learn VHDL so I can program a small Virtex2 with some test > structures. After scanning some of the messages here, I'm not sure if > I should use XST, Express, or something else. > > Is it possible to program each slice directly without having to use > primitives like RAM16x1S? I think I can make the FPGA do what I want, > but I'd like to grab the thing at a lower level. > > Any pointers or suggestions appreciated! > > Patience, persistence, truth, > Dr. mike > > -- > Mike Rosing > www.beastrider.com BeastRider, LLC > SHARC debug tools >Article: 45303
We are probably close. The flow is that the user creates regions, dumps the RTL associated with timing critical parts of his design in them, then Amplify optimizes and fully places the generated BELs inside the regions and outputs both the netlist and an NCF file containing LOC and BEL (not RLOC) constraints for all components in the regions. The regions can be fairly large - on the order of 2000 slices. Logic not in a region is left unconstrained in the current version. We do have a routing model on which we perform routing during placement and optimization to get good timing estimates, but we have no way to forward that information yet. You are correct that one still needs to run the Xilinx tool flow to finish the job. However, as you mention, the placement phase becomes much faster. There is also a second pass flow that I didn't mention where we read back the NCD info, perform incremental critical path optimization and incremental placement and then send back an optimized and fully placed design for routing. Ray Andraka wrote: > Ken, I think we might both saying the same thing, but perhaps not clearly. As I > understand Amplify, it essentially puts RLOCs and BELs on the instances to create a > placement, which is then passed into the tools to direct the placement of the > primitives on the FPGA. As far as I know, Amplify is not producing an NCD file, so in > order to get from the Amplify output to a state where the design can be routed, it > first has to pass through the xilinx placer. The xilinx placer has an easy job in > this case, since all it has to do with a fully RLOC'd design is to put all the BELs > where the constraints say they belong. Nevertheless, you still need to run the xilinx > tool flow from the beginning to take care of all the translations. Please correct me > if I am wrong. This is basically the same mechanism we use for our placed macros and > a good deal of our high performance/high density work. > > It would be nice if there were real hooks to direct routing too. I am aware (thanks > to Philip) now of the wire numbering constraints for route, but like you (Ken) > mentioned in another post, it is not general enough to make a router out of it, at > least as far as I can tell. > > > > Ken McElvain wrote: > > >>>Amplify is not a router, It does placement using the mechanisms for externally >>>applied floorplanning provided by the FPGA tools. You still need to run the >>>design through the tool to get the full placement as well as the route and >>>bitstream. >>> >>Sorry Ray, old data. The more recent versions of Amplify perform a full >>placement for all instances in the regions you make as part of the >>optimization flow. We also do detailed estimation of the routing as >>part of the placement so we get the timing right. There is no current >>interface to pass routing forward. You are correct about having to run >>the design through the Xilinx P&R tools to finish the placement of >>instances outside of the regions and to do routing. >> >> >>> >>>>Amplify, as reffered to by Ken is not a place and route tool, but rather a >>>>"physical optimizer" as it calls itself. It helps the vendors place and >>>>route tool a lot in terms of finding much better placement but has nothing >>>>to do with routing phase (but maybe just to ensure a routing is possible >>>>...). Again in this case I doubt that Synplicity has ever had access to all >>>>detials of Virtex series configuration internals... >>>> >>>>Best Regards >>>>Arash >>>> >>>> >>>-- >>>--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 >>> >>> >>> >>> > > -- > --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: 45304
I am now the proud owner of a Spartan IIe test card. Playing around in WebPACK with the verilog source files that came with the card has resulted in 38 different files all sharing the same base name. Confusing. What I need is to learn both Verilog and the entire simulation and implementation processes from scratch. I have worked with different kinds of digital electronics before, just not FPGAs. Do you recommend any litterature that could give me a nice start? I have tried the ISE tutorial, but I'm still left with pretty basic questions like "how do I generate an EDIF file from my Verilog code, and why" Regards, BørgeArticle: 45305
Hi I'm beginning on my first CPLD/FPGA design with the Xilinx products. I allready have the Foundation Series 1.3 Software with the associated Parallel Cable III. I wonder if any of you experts can answer theese questions: 1. I actually have a copy of the "Active HDL 3.5" software - what would you use: Active HDL, Foundation Series or the WebPack? Moreover if one uses the Active HDL package is the link to the programming via the Parallel Cable simple/doable? 2. I checked the Xilinx website with regards to the cost of the XC9500 versus the XC9500XL and the XL version was very much cheaper (1$ as opposed to 3$ for the simplest chip). Is the only difference just that the XL is a 3.3V version - or is the XC9500 being outfaced? 3. My first circuit is going to consist of a 32bit adder (for a DDS circuit) and a 4digit 7-segment display driver. The display driver can easily fit in a XC9536XL chip and is simple (I don't even need driver BJTs because the XC9500 can drive 20mA LEDs directly) but I'm not sure how large a device is needed for the 32bit adder. As 4-5 XC9536XL chips is nearing the cost of a XC5200 chip (with 256 registers) would I be better off with the XC5200. As for programming I have a microcontroller that can program the XC5200 at power-up - so I guess that is not a problem). More to the point - what are the major differences of the XC9500 series versus the XC5200 (is the XC5200 more optimal for complex designs? Arithmetics?) Thanks KlausArticle: 45306
SneeR wrote: > HI, where i can find AMBA specyfication? http://www.arm.com/armtech/AMBA_Spec?OpenDocumentArticle: 45307
Looks like the only real difference from what I said is that you generate LOCs instead of
RLOCs. Guess that doesn't help much if you are disabling port I/O to drop a compiled design
into a higher level as an edif black box. We do that reasonably frequently to cut down the
compile time/memory and to lock the results of a block. RLOCs work with that since they are
relative and resolved by the xilinx S/w. LOCs don't work there if you have more than one
instance of the block.
I was also aware of your incremental improvement step.
Ken McElvain wrote:
> We are probably close. The flow is that the user creates regions, dumps
> the RTL associated with timing critical parts of his design in them,
> then Amplify optimizes and fully places the generated BELs inside the
> regions and outputs both the netlist and an NCF file containing LOC and
> BEL (not RLOC) constraints for all components in the regions. The
> regions can be fairly large - on the order of 2000 slices. Logic not in
> a region is left unconstrained in the current version. We do have a
> routing model on which we perform routing during placement and
> optimization to get good timing estimates, but we have no way to forward
> that information yet.
>
> You are correct that one still needs to run the Xilinx tool flow to
> finish the job. However, as you mention, the placement phase becomes
> much faster.
>
> There is also a second pass flow that I didn't mention where we read
> back the NCD info, perform incremental critical path optimization and
> incremental placement and then send back an optimized and fully placed
> design for routing.
>
> Ray Andraka wrote:
>
> > Ken, I think we might both saying the same thing, but perhaps not clearly. As I
> > understand Amplify, it essentially puts RLOCs and BELs on the instances to create a
> > placement, which is then passed into the tools to direct the placement of the
> > primitives on the FPGA. As far as I know, Amplify is not producing an NCD file, so in
> > order to get from the Amplify output to a state where the design can be routed, it
> > first has to pass through the xilinx placer. The xilinx placer has an easy job in
> > this case, since all it has to do with a fully RLOC'd design is to put all the BELs
> > where the constraints say they belong. Nevertheless, you still need to run the xilinx
> > tool flow from the beginning to take care of all the translations. Please correct me
> > if I am wrong. This is basically the same mechanism we use for our placed macros and
> > a good deal of our high performance/high density work.
> >
> > It would be nice if there were real hooks to direct routing too. I am aware (thanks
> > to Philip) now of the wire numbering constraints for route, but like you (Ken)
> > mentioned in another post, it is not general enough to make a router out of it, at
> > least as far as I can tell.
> >
> >
> >
> > Ken McElvain wrote:
> >
> >
> >>>Amplify is not a router, It does placement using the mechanisms for externally
> >>>applied floorplanning provided by the FPGA tools. You still need to run the
> >>>design through the tool to get the full placement as well as the route and
> >>>bitstream.
> >>>
> >>Sorry Ray, old data. The more recent versions of Amplify perform a full
> >>placement for all instances in the regions you make as part of the
> >>optimization flow. We also do detailed estimation of the routing as
> >>part of the placement so we get the timing right. There is no current
> >>interface to pass routing forward. You are correct about having to run
> >>the design through the Xilinx P&R tools to finish the placement of
> >>instances outside of the regions and to do routing.
> >>
> >>
> >>>
> >>>>Amplify, as reffered to by Ken is not a place and route tool, but rather a
> >>>>"physical optimizer" as it calls itself. It helps the vendors place and
> >>>>route tool a lot in terms of finding much better placement but has nothing
> >>>>to do with routing phase (but maybe just to ensure a routing is possible
> >>>>...). Again in this case I doubt that Synplicity has ever had access to all
> >>>>detials of Virtex series configuration internals...
> >>>>
> >>>>Best Regards
> >>>>Arash
> >>>>
> >>>>
> >>>--
> >>>--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
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > --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
> >
> >
> >
--
--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: 45308Hi, We've done some tests in the lab on a XC2V6000 and got results that were not the same using fixed versus variable phase-shift. I first measure the clock-to-out for a signal that is FF in the IOB and that is clocked using a DCM with variable phase-shift = 14 at 175 MHz. I then changed the mode to fixed in fpga_editor and tied all the DCM's PS inputs to logic_0 keeping the same PS=14 and got slightly different clock-to-out. The thing is that our circuits work well when fixed but are erratic when in variable mode. Why does PS=14 lead to a different shift ? Best regards, YanickArticle: 45309
Well, I have done this tons in the past. I would indeed use the rising edge of WR and the techinques you mentioned. It's hard to give advice ... I just looked at the timing diagrams and wrote the code that latched in at the right time and acted properly to the CS & R/W lines the processor gives out. One design had it's own built in CS decoding ... so I watched the address line and when it was in my address space I responded. I did indeed use large output muxes for the dataspace. If timing or space is an issue then you can consider using internal tri-state drivers vs. the big logic mux. Spec'ing the timing in the synthesis and fitting tool is the critical part. If your bus accesses memory at 66MHz, well then your design better respond in time. If it doesn't then you might have trouble. So, I can't say I have good advice but it looks like nobody else said anything after 2-3 days ... I just look at the datasheet, compare when data will be valid to when I need it ... and I make it work ... and it's always worked in the past .... for whatever that is worth ... Good luck! JohnArticle: 45310
Does anybody have experience with the Virtex II embedded multipliers with the pipeline registers? I think there's some problems with the tool support for these. I'm only enabling these, using the clock enable, every other cycle. I specified that all inputs to the multiplier are multicycle paths. The PAR tools think that the clock enable input should also be a multicycle path. That's not supposed to happen, is it? If you specify that all paths going to a registered element are multicycle paths, the clock enable is always excluded, isn't it? (I got around this by explicitly stating that only the paths to the A and B inputs are multicycle paths.) Also, the Verilog simprim (x_mult18x18s) seems to be buggy. It flags setup violations on the A and B inputs even on clock edges for which the clock enable isn't asserted. I don't think the VHDL model does this. Anybody else experience this? Where are these pipeline registers anyway? They don't really seem to be in the middle of the multiplier cloud. For example, for a -5 part, if you use the nonpipelined multiplier, there is an 8.5ns delay through the multiplier. If you use the pipelined multiplier, there is a 3.45ns setup to the pipeline registers and then a 6.9ns delay to the multiplier output. Using the pipelined reg seems to only saves you less than 20% (although it can help if you have a long net delay to the input of the multiplier). Seems like if the pipeline registers were in the middle of the cloud you'd get more like a 50% savings. The data sheet also shows almost a 100% difference in pipelined multiplier times between the -4 and -6 part (8.1 vs 4.1ns). I'm dubious. -KevinArticle: 45311
If you were to ask a Xilinx employee about generating an EDIF
netlist from ISE WebPACK, they will tell you, "Sorry, ISE WebPACK 4.x's
XST can only generate an encrypted NGC netlist."
However, I did some experiments with XST, and regardless of what Xilinx
is saying, XST since ISE WebPACK 4.1 can still generate an EDIF netlist,
so they are basically lying.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aceeac%249fj%241%40newsreader.mailgate.org&rnum=1&prev=/groups%3Fq%3DEDIF%2BXST%2Bgroup:comp.arch.fpga%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Daceeac%25249fj%25241%2540newsreader.mailgate.org%26rnum%3D1
Also, try a tip from this posting, too (-ofmt EDIF option from ISE's
GUI.).
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=agtijp%24s8s%241%40newsreader.mailgate.org&rnum=2&prev=/groups%3Fq%3DEDIF%2BXST%2Bgroup:comp.arch.fpga%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dagtijp%2524s8s%25241%2540newsreader.mailgate.org%26rnum%3D2
Now that FPGA Compiler II no longer comes with ISE BASE-X or
Foundation, Xilinx will probably tell users who want an EDIF netlist
that they will have to go buy a third party synthesis tool, which costs
thousands of dollars, but now that I accidentally figured out that XST
can still generate an EDIF netlist, that will likely result in some lost
sales for third party synthesis tool vendors.
Yes, it's tough to compete with something that's free.
Regarding the question of how you can get started with ISE
WebPACK, I will recommend that as soon as you finish the tutorials and
understand how the design flow works, start designing something
practical.
In my case, I wanted to connect an FPGA to a computer, so I started
developing a PCI IP core, and after a year of development, it works
fine.
I used Insight Electronics Spartan-II PCI card which cost me $145 back
then (It now costs something like $225.) to test my PCI IP core with a
computer.
If a PCI IP core doesn't fascinate you, develop a 5-state 32-bit RISC
processor.
If you don't want to develop your own instruction set, borrow MIPS, ARM,
or SPARC's instruction set.
You shouldn't have any legal problems (i.e., Getting sued for patent
infringement.) using SPARC's instruction set.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
"Børge Strand" wrote:
>
> I am now the proud owner of a Spartan IIe test card. Playing around in
> WebPACK with the verilog source files that came with the card has resulted
> in 38 different files all sharing the same base name. Confusing.
>
> What I need is to learn both Verilog and the entire simulation and
> implementation processes from scratch. I have worked with different kinds of
> digital electronics before, just not FPGAs.
>
> Do you recommend any litterature that could give me a nice start? I have
> tried the ISE tutorial, but I'm still left with pretty basic questions like
> "how do I generate an EDIF file from my Verilog code, and why"
>
> Regards,
>
> Børge
Article: 45312I thought variable phase shift was broken. Is this an ES part? Bryan "Yanick" <yanick_viens@hotmail.com> wrote in message news:8a0201da.0207180957.569ed6ef@posting.google.com... > Hi, > > We've done some tests in the lab on a XC2V6000 and got results that > were not the same using fixed versus variable phase-shift. I first > measure the clock-to-out for a signal that is FF in the IOB and that > is clocked using a DCM with variable phase-shift = 14 at 175 MHz. I > then changed the mode to fixed in fpga_editor and tied all the DCM's > PS inputs to logic_0 keeping the same PS=14 and got slightly different > clock-to-out. > > The thing is that our circuits work well when fixed but are erratic > when in variable mode. > > Why does PS=14 lead to a different shift ? > > Best regards, > > YanickArticle: 45313
I am not sure what is causing your problem, but unless an internal
tri-state buffer is used, you cannot connect two wires together, and
connect that wire to a FF (or a LUT).
If what you are saying is true, and `undef is the only reason that's
causing the problem you described, you will want to modify the code so
that it won't be tying two wires together.
It's my own opinion, but the authors of Opencores.org PCI IP core seem
to have too many submodules in their design, and furthermore, they tend
to keep changing signal names throughout the design.
Those problems tend to make it really hard to follow what is going on in
the design in case someone else has to make modifications to fix
problems.
I assume you ended up going back to WebPACK ISE 3.3WP8.0's XST,
but I believe that version's XST has a bug that causes XST to go into an
infinite loop when synthesizing some designs.
The newer version of XST (XST since ISE WebPACK 4.1) shouldn't have that
problem.
However, not all designs being synthesized will exhibit the infinite
loop problem you experienced.
I believe the authors of Opencores.org PCI IP core used FPGA Express to
synthesize the design.
If you have access to it, you may want to use that, but if you are a
poor ISE WebPACK user like myself, you are stuck with XST.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
BROTO Laurent wrote:
>
> Hi all,
>
> I've downloaded the OpenCore's PCI IP Core.
> I'm working with WebPack 4.2.03 and I've got problem when I want synthetize
> the project.
>
> XST (the compiler) doesn't understand the `undef directive.
> When I remove this directive, I've got multisource in signal xyz.
>
> Therefore, I've downloaded WebPack 3.8 to have the "Resolution Style"
> option.
> With this version, I can begin to compile the PCI Bridge, but 12 hours after
> beginning, it's no yet finish.
>
> So, do you know how can I should synthetize this project ?
>
> Thanks a lot,
>
> Laurent
Article: 45314Hey Neil, the EDIF from DK1 is it architecture specific or does it produce code for a general architecture that needs further tool optimization? Noel "Neil Stainton" <neil.stainton@celoxica.com> wrote in message news:<3d2ea8a4$1@news.star.co.uk>... > Hello Mike, > > The VHDL and Verilog outputs from DK1.1 will specifically target the > following: > > - Synopsis FPGAExpress > - Exemplar LeonardoSpectrum > - Model Technology ModelSim > - Synplicity Synplify > > This option specified under the 'Linker' tab of the project settings > dialogue. > > The EDIF output can be targetted to one of a large choice of FPGA families, > the majority of which are supported by an integrated technology mapper. > > Best Regards, > > Neil Stainton > Applications Engineer > Celoxica Ltd. > > www.celoxica.com > > > > "mike" <ruibinw@hotmail.com> wrote in message > news:26c026ad.0207120109.1d29c655@posting.google.com... > > Hi, > > > > who have experience about celoxica DK1? Is it possible to generate > > VHDL/Verilog from handel c code and use Synplify or Synopsys to > > generate Gate-Level netlist? > > > > From the document, it said DK1 could generate EDIF netlist and use > > FPGA tools( such as Quartus) to place and route. But I would like to > > know the verilog generate from c code can be acceptable by othe > > Synthesis tools. Thanks a lot. > > > > mikeArticle: 45315
Yanick, Please open a case with the hotline. Typical problems we have seen are: 1) not implementing the correct interface with PSEN, PSINC/DEC, PSCLK 2) unit stops inc (or dec) due to the ES issue (fixed in susequent masks and production) This is easy to see, because PSDONE goes low, and never returns to high (indicating the internal state machineis stuck). Also please contact your FAE, Austin Yanick wrote: > Hi, > > We've done some tests in the lab on a XC2V6000 and got results that > were not the same using fixed versus variable phase-shift. I first > measure the clock-to-out for a signal that is FF in the IOB and that > is clocked using a DCM with variable phase-shift = 14 at 175 MHz. I > then changed the mode to fixed in fpga_editor and tied all the DCM's > PS inputs to logic_0 keeping the same PS=14 and got slightly different > clock-to-out. > > The thing is that our circuits work well when fixed but are erratic > when in variable mode. > > Why does PS=14 lead to a different shift ? > > Best regards, > > YanickArticle: 45316
Hi Kevin,
> The catch is, even though Xilinx says that, ISE WebPACK doesn't
> actually support Virtex-I (0.22u part), although it does support
> Virtex-E (0.18u part) up to 300K part and Spartan-II.
> If you want Virtex-I support, I believe you will have to pay for ISE
> BASE-X which costs $700.
yes, your are right.
Now i have a big problem!
I can look to the Spartan II and i see this chip is to slow for my project.
or i can look to the Virtex-E and i see this chip will not do 5V-PCI.
But i have a littel bit hope :
> Since 5V PCI is not intended to run above 33MHz, I will guess
> that most cards will likely fail at 50MHz.
I think, you are right, second.
The most modern Southbridges are produced in 0.22µm or 0.18µm
and use the same trick to be 5V-PCI "compliant". This chips can not
drive a real 5V-output but also this chips drive the max. IO-Voltage
(e.g. 3.3V) at the output-pins and the most (not all) real 5V-cards
accept this as high level.
The controler-chip on the testet 66MHz-networkcard is 5V-PCI-"compliant"
to and this is the cause the card is running without error on my board.
- theoretical : if i have a PCI-bus w/o real 5V-PCI-devices i can use
Virtex-E out of danger.
Do you think thats right ?
I have bay a board, with all includet in the chipset, spezial for my projekt.
This board don't have some onboard-PCI-devices (real nothing) and
the grafic is includet at the northbridge. I have at the moment pluged only
two peaces : RAM and CPU.
The best at this idea is the Virtex-E is faster (easy for PCI-timings) ,
cheaper and have LVD-IO's (good for the external interface).
thanx for your design-tips
i have looked at opencores.org in the free PCI-core and i hope i can use
some ideas of this design.
My PCI-core must have 3 sections :
- configuration-space-target, only 8 different dword-registers,
including decode the BE-Signals at writes
- target, only know the 2 write commands, ignore the BE-signals,
write the data into the input buffer and make a target abord if is full (8 dword's)
- initiator, wait for an full internal buffer (16 dword's) and write it with an
normal write command into the system-memory, all BE-signals activ.
i hope it make the development smarler for me.
and i did't have a delay betwen differend signaldirections on the bus
(only write commands used)
Gretings,
Erik
sorry for my terrible englisch, my favorite language is assembler.
Article: 45319Give this site a try! It has pictures and everything. http://www.corelis.com/products/jtag-analyzer.html Alan Alexander Weiss wrote: > > Hi all, > anybody knows a source for a configuration software for the HP16500B / > HP16510 logic analyzer, which displays JTAG State Information and JTAG State > Mnemonics? > > Thanks a lot in advance > > AlexanderArticle: 45320
> I just wondered what kind of PCI is used on PC motherboard? an hardcore overclocked PCI do this only if you know what you do !!!Article: 45321
HI, where i can find AMBA specyfication with timing signals (i.e. in falling edge this is tested, in "1" at that signal this signal is asserted)? LukaszArticle: 45322
Hello all... I'm a senior FPGA designer with experience in telecom and 3D graphics and also as an ASIC designer and FPGA team leader. I'm located in Ottawa, Canada (for those who don't know) but recently got laid off due to the high tech slump here in Canada so I'm currently looking for work. No luck so far... the market is really bad (and it's the summer!) and salaries have dropped quite a bit up here. I was wondering how's the job market for senior FPGA designers in the rest of Canada and USA? What about other countries? Do a lot of you work remotely? Thanks! MartinArticle: 45323
> I'm a senior FPGA designer with experience in telecom and 3D graphics and > also as an ASIC designer and FPGA team leader. I'm located in Ottawa, > Canada (for those who don't know) but recently got laid off due to the high > tech slump here in Canada so I'm currently looking for work. No luck so > far... the market is really bad (and it's the summer!) and salaries have > dropped quite a bit up here. > > I was wondering how's the job market for senior FPGA designers in the rest > of Canada and USA? What about other countries? Don't know what the job market is like up in Ottawa, so I can't compare your market with Southern California (Irvine, in particular). I can say the market here is pretty bad, due to the high-tech slump. The slump seems to have hit the San Jose area (California's "Silicon Valley") pretty hard. > Do a lot of you work remotely? I personally don't. Most engineers work >50% of their time onsite (not remotely.)Article: 45324
Austin, This is an important issue for us that we need to solve, this is why I am asking the group looking for similar experiences and a hopefuly, a solution. The PS=14 is by configuration, not obtained using the DCM PS interface. Though, we have a dcm_controller module that allows us to change the phase-shift. We probed the DCM PS interface as well as the lock signal with a logic analyzer and everything looks good, as expected. This is not an early ES device, as indicated by the JTAG code, so that errata should not apply anyway. Regards, Yanick Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D3729C9.482754BA@xilinx.com>... > Yanick, > > Please open a case with the hotline. Typical problems we have seen are: > > 1) not implementing the correct interface with PSEN, PSINC/DEC, PSCLK > > 2) unit stops inc (or dec) due to the ES issue (fixed in susequent masks > and production) This is easy to see, because PSDONE goes low, and never > returns to high (indicating the internal state machineis stuck). > > Also please contact your FAE, > > Austin > > Yanick wrote: > > > Hi, > > > > We've done some tests in the lab on a XC2V6000 and got results that > > were not the same using fixed versus variable phase-shift. I first > > measure the clock-to-out for a signal that is FF in the IOB and that > > is clocked using a DCM with variable phase-shift = 14 at 175 MHz. I > > then changed the mode to fixed in fpga_editor and tied all the DCM's > > PS inputs to logic_0 keeping the same PS=14 and got slightly different > > clock-to-out. > > > > The thing is that our circuits work well when fixed but are erratic > > when in variable mode. > > > > Why does PS=14 lead to a different shift ? > > > > Best regards, > > > > Yanick
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