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
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: (snip, I wrote) >> Usually this would be done with a barrel shifter, but they are >> not very LUT efficient in many FPGAs. If you aren't so restricted >> in cycles, though, you can use an ordinary shift register. > You can use a Multiplier as barrel shifter too (Xilinx xapp195) Usually the barrel shifter problem comes up doing floating point in an FPGA. If you use the hardware multipliers for multiplying, you might not have them avaialble. But it takes two or three for floating point add, which usually makes add bigger than multiply! For IEEE double, 53 bits is a big shifter! -- glenArticle: 152401
Marc Guardiani wrote: > On Thursday, August 18, 2011 5:18:07 AM UTC-4, Uwe Bonnes wrote: >> karl schrunk <karls...@gmail.com> wrote: >>> I'm troubleshooting the first rev of my first Spartan 6 PCB design; >>> this is sort of a learn-by-making-all-the-mistakes process, but I >>> could sure use a hint or two here from the gurus. >>> Obviously there are a million things that can lead to a board not >>> coming up, but my understanding is that very few things can lead to >>> the situation where the JTAG interface won't even shift (i.e. TDO >>> stuck at zero). >> In a hand soldered engineering design, bad contacts or shorts in the JTAG >> chain can be common... >> -- >> Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de >> >> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt >> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > What's also common is for the JTAG to be connected incorrectly. Assuming this is the only device in the chain, TDI of the programmer goes to TDI of the FPGA, _not_ TDO. Then, obviously, TDO of the programmer goes to TDO, _not_ TDI. > > As someone else already stated, make sure you have some series termination resistors (roughly 33ohm) in place. Put them as close as practical to the driving pin. That would be near the TDI, TCK, and TMS pins of the JTAG connector and TDO pin of the FPGA. Signal integrity is not dependent on the frequency of your signal, it's dependent on the edge rate. You could have signal integrity issues even at your 2400Hz. > > Also make sure that you supply ground and a reference voltage to the programmer. Make sure you have all the required pull ups and downs on the JTAG signals. > > Look at the JTAG signals on a scope and make sure that the edges look clean. Look at TDO coming out of the FPGA to see if it really is low all the time. IIRC, Xilinx has a debug mode for the JTAG programmer so that you can exercise the lines. > > -- Marc In case it didn't already get mentioned, the PROG_B pin of Xilinx FPGA's is a sort of master reset and it *does* affect JTAG operation. This pin should be pulled up. -- GaborArticle: 152402
> In case it didn't already get mentioned, the PROG_B pin of Xilinx > FPGA's is a sort of master reset and it *does* affect JTAG operation. > This pin should be pulled up. Yikes, I left it unconnected. Double yikes: I found block of ground pins that were not connected (due to the strangely-arranged Eagle schematic symbol I'm using). That's obviously a gigantic mistake, although I'd still expect all the GNDs to be internally connected by the fill on the upper metal layers, so I'm still not sure if this explains the JTAG problems, but it certainly must be fixed! Between that and Stephen (and other's) recommendations about terminating the JTAG bus (which I didn't do) and the fact that I only have one board right now, I think I've got enough possible solutions for it to be worth another run of boards (four this time in case I screw one up like I did with the last batch). I'll also bring out more of the pins so I can probe them this time. I'll report back in a week or so. Thank you all so much for your help! I really didn't expect such a great response. You guys are awesome. - kArticle: 152403
On Aug 18, 11:43=A0am, Steve <theec...@gmail.com> wrote: > >> Usually this would be done with a barrel shifter, but they are > >> not very LUT efficient in many FPGAs. =A0If you aren't so restricted > >> in cycles, though, you can use an ordinary shift register. > > > You can use a Multiplier as barrel shifter too (Xilinx xapp195) > > Given that there are plenty of clock cycles available and not much HW, > I'd spend the first 8 clock cycles looking at the two MSBs and left > shifting two positions when those MSBs are 00. =A0The detection of the > zero input special case can also be folded into this part very efficientl= y. How much clock cycles is plenty? You can: a) start with some value for D b) compute T1=3DD*D c) compute T2=3DY*T1 d) check whether T2 > K e) use nested intervals to find the exact value of D in 16 iterations. Using 16 bit iterative multipliers you are in the range of 80 luts for the datapath and 16*32 clock cycles. Using bit serial implementation you will be using even less luts for the data path and about 16*16*32 clock cycles. An even simpler solution is not to use nested intervals but making use of the fact that: Y*(D+1)*(D+1) - Y*D*D =3D 2*Y*D + 1 and 2*Y*(D+1) - 2*Y*D =3D 2*Y This means that you can scan all values of D using two additions per try: YDD_next =3D YDD + 2YD 2YD_next =3D 2YD + 2Y Note that this version uses no multipliers. resulting in 48 LUTs and 64k clock cycles (parallel) or 6 LUTs and 2M clock cycles (bit serial) 10 bit accuracy is 64 times faster at identical hardware cost. Kolja cronologic.deArticle: 152404
On 08/19/2011 09:25 AM, karl schrunk wrote: >> In case it didn't already get mentioned, the PROG_B pin of Xilinx >> FPGA's is a sort of master reset and it *does* affect JTAG operation. >> This pin should be pulled up. > > Yikes, I left it unconnected. > > Double yikes: I found block of ground pins that were not connected > (due to the strangely-arranged Eagle schematic symbol I'm using). > That's obviously a gigantic mistake, although I'd still expect all the > GNDs to be internally connected by the fill on the upper metal layers, > so I'm still not sure if this explains the JTAG problems, but it > certainly must be fixed! > > Between that and Stephen (and other's) recommendations about > terminating the JTAG bus (which I didn't do) and the fact that I only > have one board right now, I think I've got enough possible solutions > for it to be worth another run of boards (four this time in case I > screw one up like I did with the last batch). I'll also bring out > more of the pins so I can probe them this time. Hi Karl, Do take a look at Xilinx document UG380 "Spartan-6 FPGA Configuration". p48 shows the basic connections for JTAG (ignore the BPI Flash). The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done are important - only connect those three pins differently if you have a good reason and know what you're doing. Ch3 also covers JTAG and is worth a read. Have fun! Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.auArticle: 152405
>Hi, > >I tried to respond to this yesterday but it seems that my post didn't >show up? So I'll try again. > >What you are actually trying to do, and what you are asking is very >unclear, but I assume you mean that you would like to know how to load >data into the memory from the PC side. >There are a number of ways to do this, and it really depends on what >hardware you have, what kind of data rate you want, etc. > >Also from your code I see that you are using the same address input to >control both the writing and the reading, but you can have separate >address inputs for read/write, that will be much more convenient for >what I think you are probably trying to do overall. > >Lastly, what kind of hardware do you have, and what kind of interface >do you want with the host PC side? USB? A regular old serial port? >You can write a state machine in VHDL to process incoming >communication, or you can use a soft microcontroller; For a small >application like what I suspect you are possibly trying to do, I might >use a Picoblaze core, if I was using a Xilinx FPGA.. for other vendors >there are other solutions, or there are similar solutions that will >work for all vendors (various soft CPUs available at OpenCores). > >You will have to be more clear on what you're actually trying to do, >if you would like help.. but hopefully what I've said here will give >you at least an idea of what direction to take. > >Steve > thanks for reply, actually i am using nexys 2 board, and i have USB protocal.i want to send image pixels to BRAM of FPGA. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152406
"karl schrunk" <karlschrunk@gmail.com> wrote in message news:c2a98d3d-418e-4b62-ae24-8bd77be36da0@p37g2000prp.googlegroups.com... > Double yikes: I found block of ground pins that were not connected > (due to the strangely-arranged Eagle schematic symbol I'm using). > That's obviously a gigantic mistake, although I'd still expect all the > GNDs to be internally connected by the fill on the upper metal layers, > so I'm still not sure if this explains the JTAG problems, but it > certainly must be fixed! I know I have seen a FPGA checklist to walk through before you manufacture your circuit. At least Altera has one.Article: 152407
On Aug 18, 7:35=A0pm, Steve <theecobs@gmail.com> wrote: > Do take a look at Xilinx document UG380 "Spartan-6 FPGA Configuration". > Ch3 also covers JTAG and is worth a read. Oh yeah, definitely went over that. I was kind of disappointed though that they gave sample circuit diagrams for every configuration mode *except* JTAG. Oh well. > The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done Is it okay to use the internal pullups for those (by typing HSWAPEN to GND)?Article: 152408
On Aug 11, 2:26=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Jul 11, 11:46=A0am, wzab <wza...@gmail.com> wrote:
>
> > Hi,
>
> > I have prepared a heap-sorter implementation for FPGA. The sources are
> > licensed under the BSD license and
> > are available at alt.sources group.
> > [...]
>
> Hi Wojtek,
> Your work is impressive. It may be used in 16-bit integer environment.
>
The size of the "payload" and "sort_key" ("time-stamp") part of the
data record
may be defined in the sorter_pkg.vhd file, so of course it may be used
for 16-bit integers as well,
but you may use it also for much longer
> I want to know what delay time is: from the last input data to the
> first output sorted data in addition to the one sorted data out for
> every clock cycle.
The sorter is dedicated for sorting of stream of data. Therefore you
obtain the first data
before the last data enters the sorter.
The first sorted data appear on the output as soon, as the sorter is
filled with the data.
The sorter containing N levels has the capacity of M=3D2^(N+1)-1 data
records.
So the first sorted record is available on the output 2*M clock
pulses, after the first
record enters the sorter. Of course sorter may sort only the records
fitting into its storage.
Therefore the maximum distance between unsorted records in the input
stream must be not
greater than M.
You may investigate the internal operation of the sorter by
changing in the Makefile the line:
./${ENTITY} ${RUN_OPTIONS} 2>&1 > res.txt
into:
./${ENTITY} --wave=3D${ENTITY}.ghw ${RUN_OPTIONS} 2>&1 >
res.txt
Then you can open the resulting sorter_sys_tb.ghw file in the gtkwave
and check how all signals change in time.
More detailed description will be available in my paper prepared for
Proceedings of SPIE,
however according to SPIE policy I can not publish it yet.
>
> Your Heapsort's big problem is it can apply to 16-bit integer and the
> sort is not stable.
>
Yes, the Heapsort is not a stable sort algorithm. However for many
applications this is
not a problem.
Wojtek
Article: 152409On 08/19/2011 05:59 PM, karl schrunk wrote: > On Aug 18, 7:35 pm, Steve<theecobs@gmail.com> wrote: >> Do take a look at Xilinx document UG380 "Spartan-6 FPGA Configuration". >> Ch3 also covers JTAG and is worth a read. > > Oh yeah, definitely went over that. I was kind of disappointed though > that they gave sample circuit diagrams for every configuration mode > *except* JTAG. Oh well. > >> The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done > > Is it okay to use the internal pullups for those (by typing HSWAPEN to > GND)? I strongly advise against it. Resistors cost about one tenth of a cent, I can't think of a reason to leave them out. Built in pullups are quite weak, roughly equivalent to something like 50K ohms. The pins we're talking about need to have pullups stronger than that. Have a read of this: http://www.xilinx.com/support/answers/35002.htm Regards, Stephen Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.auArticle: 152410
Hi all, I am testing a fairly slow design ( a IAMBIC keyer) and while I am dealing with slow signals (up to 120 WPM, about 10ms minimum resolution) I would like to perform very precise measurements about the timing. I have on the real board a 12/24/48Mhz clock and first surprise I got is that I cannot "feed" this precise clock to the design, because the period of a 12MHz is 83.3 periodic ns. I switched to ps to give more "digits" but ps is a way too small for any other signal I want to handle so I can't specify "human" signals like paddle activation (about 8ms) using # because it overflows. BTW, even in ps is still not totally accurate because it does not seem possible to specify decimals. So, is there a neat way to generate a testbench with exactly 12MHz clock and use at the same time a time unit in the micro second range? TIA. Giuseppe MarulloArticle: 152411
> either > through data training (testing data samples and seeing what timing > works) or through a timing feedback pathway People always say that feedback pathway can be used but never explain which way? I guess that you can give a pulse and catch response fronts by tuning the DCM phase, thus measuring the equivalent delay to mem. This looks simpler than feeding real SDRAM with test data and interpreting responses. However, it is more risky also - computation is less reliable than really working design. Also, I see that the external feedback becomes a part of DCM FB path in PLB memory controller. Nobody can explain the purpose of it! > In my experience, once the timing parameters have been determined, they're usable on all instantiations of the same circuit board using the same parts at the same speed. This contradicts to the first statement > relationship between DQS and the DDR2 controller clock is not necessarily the same all the time. ThanksArticle: 152412
On Sat, 20 Aug 2011 11:26:51 +0200, Giuseppe Marullo wrote:
> Hi all,
> I am testing a fairly slow design ( a IAMBIC keyer) and while I am
> dealing with slow signals (up to 120 WPM, about 10ms minimum resolution)
> I would like to perform very precise measurements about the timing.
>
> I have on the real board a 12/24/48Mhz clock and first surprise I got is
> that I cannot "feed" this precise clock to the design, because the
> period of a 12MHz is 83.3 periodic ns.
>
> I switched to ps to give more "digits" but ps is a way too small for any
> other signal I want to handle so I can't specify "human" signals like
> paddle activation (about 8ms) using # because it overflows.
>
> BTW, even in ps is still not totally accurate because it does not seem
> possible to specify decimals.
>
> So, is there a neat way to generate a testbench with exactly 12MHz clock
> and use at the same time a time unit in the micro second range?
> TIA.
>
> Giuseppe Marullo
It is not possible to represent a 12MHz clock in a simple manner with the
simulator resolution set to microseconds.
It is possible to generate a clock with a frequency of 12MHz provided
that the timing resolution of the simulator is 10ns or smaller.
(Note, typically simulator resolutions can only be set to 1 fs, 10 fs, ...
1 ns, 10 ns, 100 ns etc.)
I just simulated this code with a 1 ns simulator resolution, and it
produced a 12 MHz clock. This frequency is a long term average though;
in the short term there will be jitter as high as 1 ns due to the timing
resolution.
`timescale 1 ns / 1 ns
module twelve_MHz
(
output reg clk = 0
);
initial forever begin
#41 clk <= !clk;
#42 clk <= !clk;
#42 clk <= !clk;
end
endmodule
Consider what I've done: the times between transitions (i.e. half
periods) are, in sequence, 41ns, 42ns, 42ns, 41ns, 42ns, 42ns, etc. The
long term average is 41.667 ns, giving exactly 12MHz.
Had the simulator resolution been 10 ns, we would have needed a repeating
sequence like:
40ns, 40ns, 40ns, 40ns, 40ns, 50ns.
This is known as a fractional divider, and there are many ways of
designing these.
For simulation purposes I use a module that takes a real parameter to
specify the desired frequency in Hz. It works for frequencies up to half
of the reciprocal of the timing resolution of the simulator.
Regards,
Allan
Article: 152413I am new to VHDL and need some advice on connecting a vector array on an entity using a port map.I have an array of std_logic_vectors(63 downto 0) as a port. There are 3 of these in the array. How do I connect these 3 vectors using a port map? TIA Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152414
On Sat, 20 Aug 2011 09:47:16 -0500, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
>I am new to VHDL and need some advice on connecting a vector array on an
>entity using a port map.I have an array of std_logic_vectors(63 downto 0)
>as a port. There are 3 of these in the array. How do I connect these 3
>vectors using a port map?
So it's something like this:
library ieee;
use ieee.std_logic_1164.all;
package vec_array_pkg is
type a_3x64 is array(0 to 2) of std_logic_vector(63 downto 0);
end package;
library ieee;
use ieee.std_logic_1164.all;
use work.vec_array_pkg.all;
entity has_array_port is
port ( p: in a_3x64; ...
If your external signal is also an array of three 64-bit SLVs, then
simply connect the external array signal to the port. They have
the same type, and so can be connected.
If your external signal is really three separate 64-bit
signals, then proceed like this:
signal P,Q,R: std_logic_vector(63 downto 0);
...
my_instance: entity work.has_array_port
port map ( p(0) => P, p(1) => Q, p(2) => R, ...
--
Jonathan Bromley
Article: 152415>On Sat, 20 Aug 2011 09:47:16 -0500, "maxascent" ><maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > >>I am new to VHDL and need some advice on connecting a vector array on an >>entity using a port map.I have an array of std_logic_vectors(63 downto 0) >>as a port. There are 3 of these in the array. How do I connect these 3 >>vectors using a port map? > >So it's something like this: > > library ieee; > use ieee.std_logic_1164.all; > package vec_array_pkg is > type a_3x64 is array(0 to 2) of std_logic_vector(63 downto 0); > end package; > > library ieee; > use ieee.std_logic_1164.all; > use work.vec_array_pkg.all; > entity has_array_port is > port ( p: in a_3x64; ... > >If your external signal is also an array of three 64-bit SLVs, then >simply connect the external array signal to the port. They have >the same type, and so can be connected. > >If your external signal is really three separate 64-bit >signals, then proceed like this: > > signal P,Q,R: std_logic_vector(63 downto 0); > ... > my_instance: entity work.has_array_port > port map ( p(0) => P, p(1) => Q, p(2) => R, ... > >-- >Jonathan Bromley > I really want the type to be something like this constant M : positive := 64; type a_nxm is array(natural range <>) of std_logic_vector(M-1 downto 0); and then entity has_array_port is generic( IP_NUM : integer := 3; ); port ( p: in a_nxm(0 to IP_NUM-1) Not sure if I have written this correctly? What I am trying to do is create a generic mux. So for example, I may want 3, 64 bit slv. Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152416
On Aug 20, 2:53=A0am, valtih1978 <d...@not.email.me> wrote: > =A0> either > =A0> through data training (testing data samples and seeing what timing > =A0> works) or through a timing feedback pathway > > People always say that feedback pathway can be used but never explain > which way? I guess that you can give a pulse and catch response fronts > by tuning the DCM phase, thus measuring the equivalent delay to mem. > This looks simpler than feeding real SDRAM with test data and > interpreting responses. However, it is more risky also - computation is > less reliable than really working design. Also, I see that the external > feedback becomes a part of DCM FB path in PLB memory controller. Nobody > can explain the purpose of it! > > =A0> In my experience, once the timing parameters have been determined, > they're usable on all instantiations of the same circuit board using > the same parts at the same speed. > > This contradicts to the first statement > > =A0> relationship between DQS and the DDR2 controller clock is not > necessarily the same all the time. > > Thanks Back in the Virtex/Virtex-II families the DCM with an external feedback path was used with SDRAM memory to increase the maximum data rate. The original clock would come into a DCM that would feed an output buffer. On the PCB the net would be routed from the FPGA to the SDRAM memory for 50% then split in two with one route continuing to the SDRAM and the other returning to the FPGA. This would present the same clock at both FPGA pin and the SDRAM memory. Inside the FPGA the clock feedback pin would be routed to the original DCM to remove all of the internal and PCB delay and compensate for any voltage and temperature variations. Ed McGettigan -- Xilinx Inc.Article: 152417
On Sat, 20 Aug 2011 10:24:33 -0500, "maxascent" wrote:
>I really want the type to be something like this
>
>constant M : positive := 64;
>type a_nxm is array(natural range <>) of std_logic_vector(M-1 downto 0);
>
>and then
>
>entity has_array_port is
>generic(
> IP_NUM : integer := 3;
>);
> port ( p: in a_nxm(0 to IP_NUM-1)
>
>Not sure if I have written this correctly?
Looks good.
> What I am trying to do is create
>a generic mux. So for example, I may want 3, 64 bit slv.
This is still fine. At the point where you instance
the mux, you know exactly what you plan to connect
to it:
signal P, Q, R, S: std_logic_vector(M-1 downto 0);
...
my_4way_mux: entity work.has_array_port
generic_map(IP_NUM => 4)
port map (p(0) => P, ..., p(3) => S, ...
The problems will start if you want THIS higher level
entity also to be configurable, because then it makes
no sense whatever to list out the port elements one
by one - such a list would be broken for any different
number of inputs than you wrote it for. So you'll need
an array signal up there in that top module too. But
that's fine:
constant SIZE: integer := 6;
signal A: array(0 to SIZE-1) of std_logic_vector(M-1 downto 0);
...
my_Nway_mux: entity work.has_array_port
generic_map(IP_NUM => SIZE)
port map (p => A, ...
Now, of course, you have the exquisite problem of
how to attach your miscellany of 64-bit signals
to the elements of A... but hey, things have to
get specific somewhere, don't they? This is a
typical problem with things like data readback
muxes for a register file - the mux can be generic,
but the individual registers are all different and
it's hard to parameterize their existence.
Sometimes you can partially solve this by using
an enum type as the array index. The enum names
then denote individual registers. It doesn't
solve the problem entirely, but it can make your
eventual solution look less ugly.
--
Jonathan Bromley
Article: 152418>On Sat, 20 Aug 2011 10:24:33 -0500, "maxascent" wrote: > >>I really want the type to be something like this >> >>constant M : positive := 64; >>type a_nxm is array(natural range <>) of std_logic_vector(M-1 downto 0); >> >>and then >> >>entity has_array_port is >>generic( >> IP_NUM : integer := 3; >>); >> port ( p: in a_nxm(0 to IP_NUM-1) >> >>Not sure if I have written this correctly? > >Looks good. > >> What I am trying to do is create >>a generic mux. So for example, I may want 3, 64 bit slv. > >This is still fine. At the point where you instance >the mux, you know exactly what you plan to connect >to it: > > signal P, Q, R, S: std_logic_vector(M-1 downto 0); > ... > my_4way_mux: entity work.has_array_port > generic_map(IP_NUM => 4) > port map (p(0) => P, ..., p(3) => S, ... > >The problems will start if you want THIS higher level >entity also to be configurable, because then it makes >no sense whatever to list out the port elements one >by one - such a list would be broken for any different >number of inputs than you wrote it for. So you'll need >an array signal up there in that top module too. But >that's fine: > > constant SIZE: integer := 6; > signal A: array(0 to SIZE-1) of std_logic_vector(M-1 downto 0); > ... > my_Nway_mux: entity work.has_array_port > generic_map(IP_NUM => SIZE) > port map (p => A, ... > >Now, of course, you have the exquisite problem of >how to attach your miscellany of 64-bit signals >to the elements of A... but hey, things have to >get specific somewhere, don't they? This is a >typical problem with things like data readback >muxes for a register file - the mux can be generic, >but the individual registers are all different and >it's hard to parameterize their existence. > >Sometimes you can partially solve this by using >an enum type as the array index. The enum names >then denote individual registers. It doesn't >solve the problem entirely, but it can make your >eventual solution look less ugly. >-- >Jonathan Bromley > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152419
>On Sat, 20 Aug 2011 10:24:33 -0500, "maxascent" wrote: > >>I really want the type to be something like this >> >>constant M : positive := 64; >>type a_nxm is array(natural range <>) of std_logic_vector(M-1 downto 0); >> >>and then >> >>entity has_array_port is >>generic( >> IP_NUM : integer := 3; >>); >> port ( p: in a_nxm(0 to IP_NUM-1) >> >>Not sure if I have written this correctly? > >Looks good. > >> What I am trying to do is create >>a generic mux. So for example, I may want 3, 64 bit slv. > >This is still fine. At the point where you instance >the mux, you know exactly what you plan to connect >to it: > > signal P, Q, R, S: std_logic_vector(M-1 downto 0); > ... > my_4way_mux: entity work.has_array_port > generic_map(IP_NUM => 4) > port map (p(0) => P, ..., p(3) => S, ... > >The problems will start if you want THIS higher level >entity also to be configurable, because then it makes >no sense whatever to list out the port elements one >by one - such a list would be broken for any different >number of inputs than you wrote it for. So you'll need >an array signal up there in that top module too. But >that's fine: > > constant SIZE: integer := 6; > signal A: array(0 to SIZE-1) of std_logic_vector(M-1 downto 0); > ... > my_Nway_mux: entity work.has_array_port > generic_map(IP_NUM => SIZE) > port map (p => A, ... > >Now, of course, you have the exquisite problem of >how to attach your miscellany of 64-bit signals >to the elements of A... but hey, things have to >get specific somewhere, don't they? This is a >typical problem with things like data readback >muxes for a register file - the mux can be generic, >but the individual registers are all different and >it's hard to parameterize their existence. > >Sometimes you can partially solve this by using >an enum type as the array index. The enum names >then denote individual registers. It doesn't >solve the problem entirely, but it can make your >eventual solution look less ugly. >-- >Jonathan Bromley > Ok so I have done the above and have and instantiate the mux with 3, 64-bit inputs. I try and connect a 64-bit vector to one of the inputs and when I try and simulate I get the following error. Signal "app_rd_data_i" is type ieee.std_logic_1164.std_logic_vector; expecting type ieee.std_logic_1164.std_logic. The signal "app_rd_data_i" is a 64-bit slv and I try and connect it to one of the mux inputs. Not quite sure why it thinks the mux input is std_logic? TIA Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152420
On Sat, 20 Aug 2011 14:10:54 -0500, "maxascent" wrote: >Ok so I have done the above and have and instantiate the mux with 3, 64-bit >inputs. I try and connect a 64-bit vector to one of the inputs and when I >try and simulate I get the following error. > >Signal "app_rd_data_i" is type ieee.std_logic_1164.std_logic_vector; >expecting type ieee.std_logic_1164.std_logic. > >The signal "app_rd_data_i" is a 64-bit slv and I try and connect it to one >of the mux inputs. Not quite sure why it thinks the mux input is >std_logic? Sounds as though you have put a std_logic_vector port on your mux entity, rather than an array port. The basic idea is perfectly sound; something must be messed up somewhere. -- Jonathan BromleyArticle: 152421
>Sounds as though you have put a std_logic_vector port on >your mux entity, rather than an array port. The basic >idea is perfectly sound; something must be messed up >somewhere. >-- >Jonathan Bromley > I fixed the problem; I had left an old component declaration in the package. I just have one final question. If I have the following type in a package :- constant MUX_DATA_BITS : integer := 64; constant MUX_IP_NUM : integer := 8; type mux_array is array(0 to MUX_IP_NUM-1) of std_logic_vector(MUX_DATA_BITS-1 downto 0); How do I override the two constants when I instantiate my mux so that I can have different input vectors and input numbers? Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152422
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > >>Sounds as though you have put a std_logic_vector port on >>your mux entity, rather than an array port. The basic >>idea is perfectly sound; something must be messed up >>somewhere. >>-- >>Jonathan Bromley >> > >I fixed the problem; I had left an old component declaration in the >package. I just have one final question. If I have the following type in a >package :- > >constant MUX_DATA_BITS : integer := 64; >constant MUX_IP_NUM : integer := 8; >type mux_array is array(0 to MUX_IP_NUM-1) of >std_logic_vector(MUX_DATA_BITS-1 downto 0); > >How do I override the two constants when I instantiate my mux so that I can >have different input vectors and input numbers? These sort of 'problems' are best solved by creating a function. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152423
I am trying to create a generic mux that I can just instantiate in any design. I have done this in Verilog quite easily, but it seems VHDL is a different matter. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152424
On Sun, 21 Aug 2011 08:13:29 -0500, "maxascent" wrote:
>I am trying to create a generic mux that I can just instantiate in any
>design. I have done this in Verilog quite easily, but it seems VHDL is a
>different matter.
It's actually much *easier* and *better* in VHDL, but to
see why you must be prepared to try some new ideas.
Here's your generic mux, done without any generics.
Assume there's a package containing the
following declarations (there is, isn't there?):
constant M: positive := 64; -- bit width
subtype word_M is std_logic_vector(M-1 downto 0);
type word_M_array is array(natural range <>) of word_M;
Now we can do this:
entity M_bit_generic_mux is
-- note: no generics (parameters) needed
port (data: in word_M_array; -- no bounds
selector: in std_logic_vector;
result: out word_M);
end;
architecture A of M_bit_generic_mux is
begin
-- Paranoia first.
assert 2**selector'length >= data'high
and data'low >= 0
report integer'image(selector'length)
& "-bit selector is too narrow for range "
& integer'image(data'low) & " TO "
& integer'image(data'high)
severity failure;
-- Now do the real mux
process (data, selector)
variable r: word_M;
begin
r := (others => '0'); -- or other default value
for i in data'range loop
if i = to_integer(unsigned(selector)) then
r := r or data(i);
end if;
end loop;
result <= r;
end process;
end;
The ports without bounds are known as "unconstrained"
array ports, and each instance of the entity gets its
port's size from the size of whatever signals you choose
to connect to that port. So now I can hook up the mux
like this:
signal sig0, sig1, sig2: word_M;
signal selector: std_Logic_vector(1 downto 0);
signal result; word_M;
...
three_input_mux: entity work.M_bit_generic_mux
port map (data(0) => sig0, data(1) => sig1, data(2) =>sig2,
selector => selector, result => result);
and the design automatically resizes itself to suit the (0 to 2)
input array. Equally you could use an array signal for the inputs:
signal in_sigs: word_M_array(4 to 7);
signal selector3: std_logic_vector(2 downto 0);
signal result4to7: word_M;
...
four_input_mux : entity work.M_bit_generic_mux
port map (data => in_sigs,
selector => selector3,
result => result4to7);
Note that the assertion would have tripped if you had
tried to use signal "selector" in this case, because its
two bits can't address elements 4 to 7.
Hope this helps.
--
Jonathan Bromley
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