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
Andy Ross wrote:
> On Apr 10, 2:51 pm, John Eaton <nos...@spam.com> wrote:
>> < bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
>> ---
>> > bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf
>
> Good catch. Fixed in the tarball (didn't bother with versioning).
>
> FWIW: your diff order is swapped. And, dude: non-unified diff output?
> Raised in a barn?
>
> Andy
Hate to show my ignorance but what is "unified diff output"? All I did
was to diff the fixed script against the original.
I don't have a nexys2 board but will try to get this working with a
basys and a nexys board.
John Eaton
Article: 139751On Apr 11, 3:36=A0pm, rickman <gnu...@gmail.com> wrote: > On Apr 11, 3:30=A0pm, fpgaasicdesig...@gmail.com wrote: > > > > > Hi, > > > If I have to decimate by 10. > > > Is it better to create a second clock2=3D1/10 clock1 from a counter > > or > > in the second stage working at clock2, make work this part on clock1 > > in multi-cycle > > > always@(posedge clock1) > > if (reset) > > ... > > else > > if (count=3D9) > > =A0 =A0design to work at clk2 > > end > > end > > > or > > > always @posedge clock2 > > if (reset) > > ... > > else > > design working at clk2 > > end > > > I guess it is safety to use all on clock1 domain, easier for the > > synthesis tool... > > We don't have to take care of te delay between clock1 and clock2 > > generated with clock1 > > > Thanks > > That is exactly right, although the tool doesn't care about the > phasing of your clocks. =A0It will be up to you to deal with any issues > of crossing clock domains. =A0So you are always better off using an > enable rather than a second clock if possible. > > Rick yes it was I was thinking to do.. thanksArticle: 139752
On Sat, 11 Apr 2009 12:36:04 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: ... >> I guess it is safety to use all on clock1 domain, easier for the >> synthesis tool... >> We don't have to take care of te delay between clock1 and clock2 >> generated with clock1 >> >> Thanks > >That is exactly right, although the tool doesn't care about the >phasing of your clocks. I'm not exactly sure about how you mean this. The tool (xst or trace or any other synthesis, sta tool) certainly cares about your clocks and assuming you constrain them correctly pays attention to the phase. While calculating the timing, all STA tools take phase difference between the source and the destination clock into consideration and the timing reports show this. In FPGAs you can generate very explicit phase differences by using PLL/DCM blocks and the timing reports show you that difference. And most importantly they tell you when your timing is failing because of excessive phase. > It will be up to you to deal with any issues of crossing clock domains. It's true that divided clocks need a little bit more attention to detail than otherwise but I think this is only marginal. The main issue is that the phase difference in a divided clock scheme doesn't vary over time which is the main problem with crossing clock domains in general. So the problem in this case is much simpler. The phase difference is bounded which is no different than any clock buffer in any clock tree; but the frequency is different which needs you to pay attention to pulse widths and availability which should be give no trouble to any competent digital designer. > So you are always better off using an enable rather than a second clock if possible. Not always; Divided clocks may give you a lower power circuit. Whether the power difference justifies the minor extra effort is a matter of evaluation. Sometimes, it's easier to use enables and let the back-end convert them to gated clocks but this also requires understanding of the script language of your backend and usually requires a synchronous gating cell. Also if you do this per cell, the power savings are not as high as they can be if you did this at a higher branch in the clock tree. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139753
Hi, Checked zillions of search results but could not find my answer. In EDK, I added a GPIO other ends of which is connected to some VHDL described stuff. Did some I/O and it seems to work. I read GPIO pdf file and API functions by right clicking on the GPIO component in EDK system assembly view. I just could not relate them. For example GPIO has _in, _d_out and _IO ports and corresponding registers (kind of). I felt like if I put something on the port using XGpio_DiscreteWrite it will appear at _d_out, and read using XGpio_DiscreteRead I will be reading from _in. But some API functions (their parameters) like XGpio_SetDataDirection contradict with this belief. Why would I set data direction when I and O are actually different? Does it only work for _IO port? Am I totaly lost? Thanks for any possible enlightment.Article: 139754
jleslie48 wrote:
>>> I developed a message stream using a 32Mhz clock fpga ...
>>> I switched to a 40Mhz clock fpga,
> I still have no idea why making the loop iterate 10 times vs 9 would
> result in such catastrophic failure.
Maybe the failure is due to increasing the clock frequency.
What does static timing say about Fmax?
-- Mike Treseler
Article: 139755On Apr 11, 4:46=A0pm, "Ged" <ciro.ross...@alice.it> wrote: > Hallo! > I'm Giuseppe an italian (informatic) engineering student. My professor us= es > a XSA-50 to make same interesting and amazing experiment. Is there someon= e > that know where i can buy this board? Xess' site tells it isn't in stock. > Can you help me? Thank you very much! > > Best regards, > =A0 =A0 =A0 =A0 Giuseppe Look Giuseppe, Why buying a discontinued board for which you will get no more support and you can throw it away in 2 years? Be reasonable and buy Xilinx Spartan-3A Starter Kit (http://www.xilinx.com/products/devkits/HW- SPAR3A-SK-UNI-G.htm). You can get lots of ready made reference designs (http://www.xilinx.com/products/boards/s3astarter/ reference_designs.htm). I bet they are better than what your professors. Cheers, AlesArticle: 139756
On Sat, 11 Apr 2009 13:09:00 -0700 (PDT), monurlu@gmail.com wrote: >Hi, >Checked zillions of search results but could not find my answer. >In EDK, I added a GPIO other ends of which is connected to some VHDL >described stuff. Did some I/O and it seems to work. >I read GPIO pdf file and API functions by right clicking on the GPIO >component in EDK system assembly view. I just could not relate them. >For example GPIO has _in, _d_out and _IO ports and corresponding >registers (kind of). I felt like if I put something on the port using >XGpio_DiscreteWrite it will appear at _d_out, and read using >XGpio_DiscreteRead I will be reading from _in. But some API functions >(their parameters) like XGpio_SetDataDirection contradict with this >belief. Why would I set data direction when I and O are actually >different? Does it only work for _IO port? Am I totaly lost? > >Thanks for any possible enlightment. M, The issue is that I & O are not actually independent. GPIO (by looking at the schematic here http://www.xilinx.com/support/documentation/ip_documentation/opb_gpio.pdf) support bi-directional ports mainly and what one actually reads is controlled by before the GPIO_DATA_IN register. To be able to read/write succesfully you need access to GPIO_TRI register which controls whether the output is tri-state (and therefore you can read what the outside is driving) or whether it's actually driving the GPIO_DATA to GPIO_IO (writing to outside assuming that their driver is off). You seem to be implementing a uni-directional connection to an internal VHDL block so you don't need the full glory of the GPIO ie the tri-state buffer is not needed in your case but the buffer at the input of the input register still needs to be connected correctly which the XGpio_SetDataDirection will do for you probably. You can probably make a custom GPIO which is specifically uni-directional which could remove GPIO_TRI, and the mux. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139757
Rick,
Despite that FPGAs contain almost only multiplexers,
they are quite bad in implementing multiplexers...
This is how to implement a 4:1 MUX in two 4-input LUTs:
a -|m| LUT1
|u|----|m|
b -|x| |u|----------
s0--|-----|x| | LUT2
s1---------| |-----|m|
c--|m| |u|------mux_out
|u|----|x|
d--|x| |
s1----------|
The trick is that the wire between LUT1 and LUT2 carry (dependent
on S1) once the result of the a/b mux or the value of s0.
XST does it diferent by implementing 2 times a 2:1 mux in one
slice and multiplexing the result with the F5MUX:
a -|m|
|u|----|F|
b -|x| |5|
s0--| |m|
|u|--------mux_out
c -|m| |x|
|u|----| |
d -|x| |
s0--| |
s1---------|
With 6 input LUTs, a 4:1 multiplexer becomes trivial.
You can compare this with the Synplify results.
regards
Dirk
rickman wrote:
> I am trying to get an optimum usage of LUTs in a basic mux. I think
> the part that is confusing the tool is that I am trying to save LUTs
> by using the unused input on the first LUT as an enable. The tool
> seems bright enough to combine two LUT4s into a 4 to 1 mux using the
> extra logic for that provided in the slice. But it looses any idea of
> what to do with the unused input.
>
> Here is the code for the 4 to 1 mux with enable.
>
> with DatSel (1 downto 0) select MuxLft <= -- 2 * DAWTH LUTs
> DatLog and (DAWTH-1 downto 0 => not DatSel(2)) when "00",
> MemRdDat and (DAWTH-1 downto 0 => not DatSel(2)) when "01",
> DatAdd and (DAWTH-1 downto 0 => not DatSel(2)) when "10",
> ShftDat and (DAWTH-1 downto 0 => not DatSel(2)) when "11",
> resize("0", DAWTH) when others;
>
> I have two of these and a third which is just a 2 to 1 mux. The two 4
> to 1 muxes are or'ed (since they are already enabled by select bit 2)
> and muxed with the 2 to 1 mux output in another level of LUTs.
>
> DatMux <= MuxLft or MuxRgt when DatSel (3) = '0' else MuxHigh;
>
> The tool (Synplicity) seems intent in making this much more complex
> than it needs to be. Mostly it seems to want to push the enable
> through to additional logic after the first mux.
>
> It just seems like the tool is working very hard to produce a non-
> optimal solution. This is not much different from the adders where
> it duplicates the sum output of the first bit using extra logic
> instead of just using the bit from the adder chain which has to be
> calculated anyway to determine the carry into the second bit.
>
> Is this a problem with Synplify?
>
> Rick
Article: 139758On Apr 11, 9:51=A0am, Andy <jonesa...@comcast.net> wrote: > This may sound silly, but did you try a simple 16:1 mux (albeit it > sounds like some of the choices would be the same value)? And did it > not meet timing, or were you just unhappy with the apparent > inefficiency? I've often had Synplify and other tools do a better job > with a simple description than with one in which I tried to hint to it > how I thought it could do better. Also, I usually had to use > constraints to keep it from burying/reorganizing signals when I wanted > to strongly hint a certain structure. > > I have seen Synplify create some seemingly wasteful implentations in > an effort to improve performance for the placed and routed > implementation (i.e. considering likely routing delays from relative > locations of circuit elements). Keep in mind, by pushing back the > select line [datsel(2)] to the unused input of the LUT, you are > quadrupling its fanout (with associated delay), and increasing routing > congestion. > > Andy Thanks for your reply. I gave the N input mux a shot and it did some up with a lot fewer LUTs. I duplicated some of the entries to round it up to 16 inputs allowing some to have don't cares on some of the select lines. But... they seem to have reduced the LUT count by using some special 2 input muxes in this particular architecture. It seems that the Lattice parts have a mux in each slice to combine the outputs of the two LUT4s, but also a separate 2 input mux with separate inputs and select line from the LUT4s and the other mux. So they are still not using the fourth input on any of the LUT4s. I had a similar problem optimizing muxes in some of the Altera products. They use a very different backbone for the carry propagation, a chain of OR gates with one input from the prior cell OR gate and one input from the current LUT. This should be usable to make wide input muxes by creating select signals with each input ANDed by its select signal and the rest of the logic just being a very wide OR gate. I may have some details wrong, but it was like that. I found it very hard to come up with a coding style that would use this backbone to make a wide mux. I guess I'll stick with the "standard" mux design since that gives good results in this architecture and at least has a shot at working well in any other. This implementation may not use extra LUTs, but it will be slower. We'll see if it ends up in the critical path. RickArticle: 139759
hassen.karray@gmail.com wrote: > Hi, > > I have to generate a partial bitstream for Xilinx spartan 3 devices > for dynamic reconfiguration. > > My question is about the bitgen partial mask option. i think it is not > well documented in the Bitgen manual. i just don't understand how it's > working. everytime i'm getting a diffrent strange bitstream. > The PartialMask settings are a little bit complex. You have to apply a hex-encoded bitmask with a 1 for all particular columns to be included in the partial bitfile and a 0 for the skipped ones. Look into the Virtex-II User Guide that describes these things in detail. As an alternative, you can use our tool bitscan that is included in our toolchain ReCoBus-Builder. Bitscan allows generating partial bitstreams by simply defining a two-dimensional bounding box. If you specify a 0 for the top column, the top I/O-cells will be included und, accordingly, the bottom I/O-cells are included if you set the column to the total number of CLB-rows plus 1. The ReCoBus-Builder is the most advanced tool for implementing runtime reconfigurable systems for Spartan-3 (and Virtex-II/IIPro) FPGAs and it can be downloaded from our project website: www.recobus.de (in English language) There are a lot of issues to know when partially reconfiguring S3-devices at runtime. I have a paper on this that can be also found on the website in the publications section Happy reconfiguring! Dirk > C:\Xilinx\10.1\ISE\bin\nt\bitgen.exe -w -g ActiveReconfig:Yes -g > PartialMask0:1 -g PartialMask0:0 -g PartialMask0:0 ... > > By putting a patialmask on 1 what i'm i omitting and what am i > including in the bitstream. Then how can i figure the adresses of > Columns , i'm using FPGA editor to find them :) what about the number > in hexadecimal .. > > (I am aware that Dyamic partial reconfiguration is not recommended for > Spartan3s ...) > > Best regards, > Hassen.Article: 139760
Yes, I've seen the approach you show using 2 LUT4s to create a 4 input
mux. That is typically not needed given that most architectures have
something like the F5MUX. Turns out the Lattice part has one of these
in each slice as well as an independent 2 input mux with separate
inputs and a separate output (as long as you aren't using the adder
which needs both logic outputs for sum and carry).
Sometimes when I try to explain how I do logic design I feel like a
dinosaur. I have a lot of biases from the "early" days of HDL when
the tools had a hard time using a FF enable if you didn't code it just
right. Lots of engineers code functionally without thinking of the
LUT usage, which is obviously not a bad thing if you have the gates to
spare and have schedules you need to meet. But clearly, the tools are
still not there in terms of being efficient even at basic structures
like muxes!
One of my first attempts at an HDL state machine using one hot
encoding created logic with all thirteen FFs as inputs. I didn't have
a graphical tool to see that with either. I had to wade through
listings of LUT equations to figure out what was going on. Once I saw
what was happening I dropped the state machine stuff and hand coded
the equations for each FF. That dropped the size by over 2/3s and
greatly increased the speed. It also worked the first time other than
one hang condition I missed. I still prefer to hand code the FF
equations for one hot state machines. It's actually very easy since
there is a direct mapping between transitions into a state and product
terms for the FF input.
Enough philosophizing. I've got work to complete.
Rick
On Apr 11, 6:32=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote:
> Rick,
>
> Despite that FPGAs contain almost only multiplexers,
> they are quite bad in implementing multiplexers...
> This is how to implement a 4:1 MUX in two 4-input LUTs:
>
> a -|m| =A0 =A0LUT1
> =A0 =A0|u|----|m|
> b -|x| =A0 =A0|u|----------
> s0--+-----|x| =A0 =A0 =A0 =A0 | =A0 =A0 LUT2
> s1---------| =A0 =A0 =A0 =A0 =A0|------|m|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0c--|m| =A0 =A0|u|------mux_out
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |u|----|x|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0d--|x| =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s1----------|
>
> The trick is that the wire between LUT1 and LUT2 carry (dependent
> on S1) once the result of the a/b mux or the value of s0.
> XST does it diferent by implementing 2 times a 2:1 mux in one
> slice and multiplexing the result with the F5MUX:
>
> a -|m|
> =A0 =A0 |u|----|F|
> b -|x| =A0 =A0|5|
> s0--| =A0 =A0 |m|
> =A0 =A0 =A0 =A0 =A0 =A0|u|--------mux_out
> c -|m| =A0 =A0|x|
> =A0 =A0 |u|----| |
> d -|x| =A0 =A0 |
> s0--| =A0 =A0 =A0|
> s1---------|
>
> With 6 input LUTs, a 4:1 multiplexer becomes trivial.
>
> You can compare this with the Synplify results.
>
> regards
> Dirk
>
> rickman wrote:
> > I am trying to get an optimum usage of LUTs in a basic mux. =A0I think
> > the part that is confusing the tool is that I am trying to save LUTs
> > by using the unused input on the first LUT as an enable. =A0The tool
> > seems bright enough to combine two LUT4s into a 4 to 1 mux using the
> > extra logic for that provided in the slice. =A0But it looses any idea o=
f
> > what to do with the unused input.
>
> > Here is the code for the 4 to 1 mux with enable.
>
> > =A0 with DatSel (1 downto 0) select =A0MuxLft <=3D -- 2 * DAWTH LUTs
> > =A0 =A0DatLog =A0and (DAWTH-1 downto 0 =3D> not DatSel(2)) =A0 =A0 =A0w=
hen "00",
> > =A0 =A0MemRdDat and (DAWTH-1 downto 0 =3D> not DatSel(2)) =A0 =A0 when =
"01",
> > =A0 =A0DatAdd =A0and (DAWTH-1 downto 0 =3D> not DatSel(2)) =A0 =A0 =A0w=
hen "10",
> > =A0 =A0ShftDat and (DAWTH-1 downto 0 =3D> not DatSel(2)) =A0 =A0 =A0whe=
n "11",
> > =A0 =A0resize("0", DAWTH) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when others;
>
> > I have two of these and a third which is just a 2 to 1 mux. =A0The two =
4
> > to 1 muxes are or'ed (since they are already enabled by select bit 2)
> > and muxed with the 2 to 1 mux output in another level of LUTs.
>
> > =A0 DatMux <=3D MuxLft or MuxRgt when DatSel (3) =3D '0' else MuxHigh;
>
> > The tool (Synplicity) seems intent in making this much more complex
> > than it needs to be. =A0Mostly it seems to want to push the enable
> > through to additional logic after the first mux.
>
> > It just seems like the tool is working very hard to produce a non-
> > optimal solution. =A0This is =A0not much different from the adders wher=
e
> > it duplicates the sum output of the first bit using extra logic
> > instead of just using the bit from the adder chain which has to be
> > calculated anyway to determine the carry into the second bit.
>
> > Is this a problem with Synplify?
>
> > Rick
>
>
Article: 139761Dear All Pleaser any one can tell me by example how can I get the number of one require to construct H matrix from degree distrbution ? how can i get fro m row and degree distribution integer values row degree for each row and \ column degree for each column and the number of ones in H matrix ( total number of edge s ) ? thanks ShereenArticle: 139762
If you want a small cheap board with lot more logic reource than the XSA-50 try our Drigmorn1 http://www.enterpoint.co.uk/component_replacements= /drigmorn1.html with prices from approximately 40 euros (plus VAT at 15% for EEC). We will also have the sister product Drigmnorn2 available shortly with a higher price tag but a lot more capabilities. As you are a student I'll also point out our university Acess Program http://www.enterpoint.co.uk/uap/uap.html which might have something useful for you. John Adair Enterpoint Ltd. On 11 Apr, 21:43, ales.gor...@gmail.com wrote: > On Apr 11, 4:46=A0pm, "Ged" <ciro.ross...@alice.it> wrote: > > > Hallo! > > I'm Giuseppe an italian (informatic) engineering student. My professor = uses > > a XSA-50 to make same interesting and amazing experiment. Is there some= one > > that know where i can buy this board? Xess' site tells it isn't in stoc= k. > > Can you help me? Thank you very much! > > > Best regards, > > =A0 =A0 =A0 =A0 Giuseppe > > Look Giuseppe, > > Why buying a discontinued board for which you will get no more support > and you can throw it away in 2 years? Be reasonable and buy Xilinx > Spartan-3A Starter Kit (http://www.xilinx.com/products/devkits/HW- > SPAR3A-SK-UNI-G.htm). You can get lots of ready made reference designs > (http://www.xilinx.com/products/boards/s3astarter/ > reference_designs.htm). I bet they are better than what your > professors. > > Cheers, > > AlesArticle: 139763
On 11 Nisan, 23:48, Muzaffer Kal <k...@dspia.com> wrote: > On Sat, 11 Apr 2009 13:09:00 -0700 (PDT), monu...@gmail.com wrote: > >Hi, > >Checked zillions of search results but could not find my answer. > > M, > The issue is that I & O are not actually independent. GPIO (by looking > -- > Muzaffer Kal > Thanks much, I now know that I need to call XGpio_SetDataDirection to make the input port a real input port. I tried and it works, that is outputs go to _d_out and inputs come from _in. (had some strugle with the endian stuff though) On the other hand if XGpio_SetDataDirection is not called inputs do not work, I get FFs. I also understand that I could design my own I and O primitive ports and save some logic. Is it realy feasible? I think I need to write some access functions also. Guess I can live with ready-to-use GPIO thing for now (at least until I become better at this)Article: 139764
shereen.ahmed wrote: > Pleaser any one can tell me by example http://lmgtfy.com/?q=Irregular+LDPC+matrixArticle: 139765
On Sat, 11 Apr 2009 12:49:07 -0700, John Eaton <nospam@spam.com>
wrote:
>Andy Ross wrote:
>> On Apr 10, 2:51 pm, John Eaton <nos...@spam.com> wrote:
>>> < bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
>>> ---
>>> > bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf
>>
>> Good catch. Fixed in the tarball (didn't bother with versioning).
>>
>> FWIW: your diff order is swapped. And, dude: non-unified diff output?
>> Raised in a barn?
>>
>> Andy
>
>Hate to show my ignorance but what is "unified diff output"? All I did
>was to diff the fixed script against the original.
>
>I don't have a nexys2 board but will try to get this working with a
>basys and a nexys board.
>
>
>John Eaton
http://en.wikipedia.org/wiki/Diff#Unified_format
Article: 139766On Apr 11, 7:46=A0pm, "Ged" <ciro.ross...@alice.it> wrote: > Hallo! > I'm Giuseppe an italian (informatic) engineering student. My professor us= es > a XSA-50 to make same interesting and amazing experiment. Is there someon= e > that know where i can buy this board? Xess' site tells it isn't in stock. > Can you help me? Thank you very much! > > Best regards, > =A0 =A0 =A0 =A0 Giuseppe Hello, If you are still interested in going with Xess as you might be comfortable with it, you can look for the Spartan 3 1 million model. It increases the gate count giving you much better room for trying more complex designs on FPGA. MakArticle: 139767
Hello, I have a XUPV2P board in which I need to put uClinux. I have probed http://www.digilentinc.com/Data/Products/XUPV2P/uclinux-xupv2p_rev_1_1.zip, but Login Input seems to be frozen. I cannot input any character. I have not been able to recompile uclinux, so I don't know if it is the problem. I have also seen https://rm-rfroot.net/xupv2p/ but I have no licenses for plb_uart16550 neither plb_ethernet_v1. So PLEASE, could anyone tell me how can I put uClinux in this board. I need it to go on with my investigation. Thanks so much my best regards peterArticle: 139768
On Sat, 11 Apr 2009 16:46:58 +0200, "Ged" <ciro.rossini@alice.it> wrote: |Hallo! |I'm Giuseppe an italian (informatic) engineering student. My professor uses |a XSA-50 to make same interesting and amazing experiment. Is there someone |that know where i can buy this board? Xess' site tells it isn't in stock. |Can you help me? Thank you very much! | |Best regards, | Giuseppe | |+++++++++++++++++++++ Giuseppe These boards occassionally come up on EBAY. Outside that there is little hope finding one new. I am not going to try and sell you a board or suggest an alternative. Just make you aware that there are others and the most HDL code can be ported to other boards with similar features. Any suitable replacement will need to have SDRAM onboard, at least 6 bit VGA capability, and a parallel port. You can learn HDL language on just about any FPGA. So which FPGA is used in not that important in learning the basics of synthesis and simulation. Many of your professor's projects that can be done on the XESS-50 can be done on other similar boards. You will definitely have to edit the UCF file to match your particular board. You will no longer be able to use the XESS tools as other boards will do FPGA configuration differently. There maybe a few tweaks to the HDL file to compile and synthesize on a different board. Then that is the fun of learning. As a student, I would take advantage of compnies that offer student prices for educational boards. You do need to shop around to see what is offered and whay fits in your budget. jamesArticle: 139769
Xilinx COE memory initialization files... ...support at least four data formats. PATTERN and BRANCH_LENGTH_VECTOR formats are too specialized to concern me right now. MEMORY_INITIALIZATION_VECTOR is easy enough. But what's the point of COEFDATA? Isn't it just another way to specify a bunch of numbers in a memory? Any pointers into the Xilinx docs would be appreciated. The best I found was an informative, but far from complete, page on "COE File Syntax". Am I right in guessing that Coregen uses the "coefficient" data in various different ways, depending on what sort of filter it's creating, and there may not necessarily be a one-to-one correspondence between coefficient values and memory contents? Thanks in advance -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 139770
Hi all, Could anyone please explain this requirement in detail or by steps: <Bit 16 of the rcom_ctl_sts register shall return a 0 within 1us when a Manchester error has been acknowledged by the processor writing a 1 to bit 16 of the rcom_ctl_sts register> I am waiting for the response...its Urgent SreenivArticle: 139771
On Apr 13, 5:47=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Xilinx COE memory initialization files... > > ...support at least four data formats. > > PATTERN and BRANCH_LENGTH_VECTOR formats > are too specialized to concern me right now. > > MEMORY_INITIALIZATION_VECTOR is easy enough. > > But what's the point of COEFDATA? =A0Isn't it just > another way to specify a bunch of numbers in a memory? > > Any pointers into the Xilinx docs would be appreciated. =A0 > The best I found was an informative, but far from > complete, page on "COE File Syntax". > > Am I right in guessing that Coregen uses the > "coefficient" data in various different ways, > depending on what sort of filter it's creating, > and there may not necessarily be a one-to-one > correspondence between coefficient values and > memory contents? > > Thanks in advance > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. dont ever use COE unless needed for some special reason AnttiArticle: 139772
Hi, I am trying to access a flash device from a microblaze processor on a Spartan 3E device. In Xilinx XPS, I instantiated the IP "External Memory Controller" with the following attributes BEGIN xps_mch_emc PARAMETER INSTANCE = flash_16Mx8b PARAMETER HW_VER = 2.00.a PARAMETER C_NUM_BANKS_MEM = 1 PARAMETER C_NUM_CHANNELS = 0 PARAMETER C_MEM0_WIDTH = 8 PARAMETER C_MAX_MEM_WIDTH = 8 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1 PARAMETER C_TCEDV_PS_MEM_0 = 75000 PARAMETER C_TAVDV_PS_MEM_0 = 75000 PARAMETER C_THZCE_PS_MEM_0 = 25000 PARAMETER C_THZOE_PS_MEM_0 = 120000 PARAMETER C_TWC_PS_MEM_0 = 1200000 PARAMETER C_TWP_PS_MEM_0 = 1200000 PARAMETER C_TLZWE_PS_MEM_0 = 0 PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 62500000 PARAMETER C_MEM0_BASEADDR = 0x80000000 PARAMETER C_MEM0_HIGHADDR = 0x80ffffff BUS_INTERFACE SPLB = mb_plb PORT RdClk = sys_clk_s PORT Mem_A = flash_16Mx8b_Mem_A PORT Mem_DQ = flash_16Mx8b_Mem_DQ PORT Mem_WEN = flash_16Mx8b_Mem_WEN PORT Mem_OEN = flash_16Mx8b_Mem_OEN PORT Mem_CEN = flash_16Mx8b_Mem_CEN END The flash documentation states that Write cycle should be a minimum of 60 ns so I put 120 ns for C_TWC_PS_MEM_0 just in case In the code, I use the following to try to write to the Flash XIo_Out8(FLASHBASEADDR,0x0090); // Request Device ID I then probed the WE# input pin of the flash with an oscilloscope but I see a low pulse of only 16 ns. I tried changing the parameters but nothing seems to affect the time the WE# signal is held low. Why doesn't the parameters I set up affect the time the WE# signal is held low? Thanks for any answer AmishArticle: 139773
On Apr 13, 11:37=A0am, axr0284 <axr0...@yahoo.com> wrote: > Hi, > =A0I am trying to access a flash device from a microblaze processor on a > Spartan 3E device. In Xilinx XPS, I instantiated the IP "External > Memory Controller" with the following attributes > > BEGIN xps_mch_emc > =A0PARAMETER INSTANCE =3D flash_16Mx8b > =A0PARAMETER HW_VER =3D 2.00.a > =A0PARAMETER C_NUM_BANKS_MEM =3D 1 > =A0PARAMETER C_NUM_CHANNELS =3D 0 > =A0PARAMETER C_MEM0_WIDTH =3D 8 > =A0PARAMETER C_MAX_MEM_WIDTH =3D 8 > =A0PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 =3D 1 > =A0PARAMETER C_TCEDV_PS_MEM_0 =3D 75000 > =A0PARAMETER C_TAVDV_PS_MEM_0 =3D 75000 > =A0PARAMETER C_THZCE_PS_MEM_0 =3D 25000 > =A0PARAMETER C_THZOE_PS_MEM_0 =3D 120000 > =A0PARAMETER C_TWC_PS_MEM_0 =3D 1200000 > =A0PARAMETER C_TWP_PS_MEM_0 =3D 1200000 > =A0PARAMETER C_TLZWE_PS_MEM_0 =3D 0 > =A0PARAMETER C_MCH_PLB_CLK_PERIOD_PS =3D 62500000 > =A0PARAMETER C_MEM0_BASEADDR =3D 0x80000000 > =A0PARAMETER C_MEM0_HIGHADDR =3D 0x80ffffff > =A0BUS_INTERFACE SPLB =3D mb_plb > =A0PORT RdClk =3D sys_clk_s > =A0PORT Mem_A =3D flash_16Mx8b_Mem_A > =A0PORT Mem_DQ =3D flash_16Mx8b_Mem_DQ > =A0PORT Mem_WEN =3D flash_16Mx8b_Mem_WEN > =A0PORT Mem_OEN =3D flash_16Mx8b_Mem_OEN > =A0PORT Mem_CEN =3D flash_16Mx8b_Mem_CEN > END > > The flash documentation states that Write cycle should be a minimum of > 60 ns so I put 120 ns for C_TWC_PS_MEM_0 just in case > > In the code, I use the following to try to write to the Flash > XIo_Out8(FLASHBASEADDR,0x0090); // Request Device ID > > I then probed the WE# input pin of the flash with an oscilloscope but > I see a low pulse of only 16 ns. I tried changing the parameters but > nothing seems to affect the time the WE# signal is held low. > > Why doesn't the parameters I set up affect the time the WE# signal is > held low? > Thanks for any answer > Amish Are you really running the PLB at 16 MHz? Theoretically the timing numbers are divided by the PLB clock period to generate the times you want using an integral number of bus clock cycles. Unless I'm reading this wrong you have: PARAMETER C_MCH_PLB_CLK_PERIOD_PS =3D 62500000 which to me would mean 62.5 ns or 16 MHz. Regards, GaborArticle: 139774
Hi, I've been playing around with ISE 10.1 (and also 9.2i) and Spartan 3- AN. When I open Project Navigator, synthesize my design and program it into FPGA using iMPACT, everything works fine. But, if I change something in the design (like, for instance, turn on the LED that was previously off), and start iMPACT again (it offers me to choose the bit file, as it did the first time), for some reason it only downloads the old design to the board, no matter that I chose the new bit file. Things work normally when I close Xilinx altogether and start it up again. Is this a bug, or did I skip some setup options? Please help, it's REALLY annoying to have to turn of the hole ISE everytime I wan't to try something new! Thanks, Ivan.
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