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
How can I solve this error? ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB component: BUF symbol "TXD_OBUF" (Output Signal = TXD) PAD symbol "TXD" (Pad Signal = TXD) Each of the following constraints specifies an illegal physical site for a component of type IOB: Symbol "TXD" (LOC=R7) Please correct the constraints accordingly. E.Can ODACIOGLUArticle: 148501
On Jul 28, 11:19=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 28 Jul 2010 02:46:40 -0700 (PDT), Rhydian <n...@rblack01.plus.com=
>
> wrote:
>
>
>
> >OK, following some advice elsewhere re inferred ROMs I have re-worked
> >the lookup table as a nested array:
>
> >type t_ax_by_ay is array(0 to 7) of std_logic_vector(3 downto 0);
> >type t_ax_by_path is array(0 to 7) of t_ax_by_ay;
>
> >Result : Exactly the same!
>
> >When declaring arrays of constants, are the elements guaranteed to be
> >assigned in the order they are declared? =A0Only I came across this bit
> >of example code
>
> >http://mysite.ncnetwork.net/reszotzl/sync_rom.vhd
>
> >where the position of each element within the array is explicitly
> >given. =A0If I don't do this, is the compiler allowed to re-order the
> >elements to minimize the logic?
>
> Explicitly giving the position ("named association") can add clarity or
> readability to a design, but for a large ROM like yours is likely to just=
add
> clutter.
>
> In its absence the compiler CANNOT re-order elements; they are guaranteed=
to be
> in the order given.
OK, thanks, that's what I thought. I could really do with a language
reference manual which covers details like this.
Meanwhile, I've resolved the problem...
[Terrible confession time]
The LUT was actually working as designed all along - but buried in the
data sheet for the switch is the detail that switch addresses don't
map sequentially to analog channels (?!)
Note to self : RTFDS properly next time...
Thanks to all who replied.
Article: 148502Me and my college are first time users of programming a FPGAs. We have bought the already assembled card Xylo-L from knjn. It has a Spartan-3E FPGA among other parts. Somewhere during the process of handling this card something has gone wrong and now when we connect power to the card it gets really hot fast. We can still put in some simple functions into the FPGA, e.g. we can make a couple of LED glow and blink. This must mean that the FPGA is not totally crashed. We have tested to reset the card with the USB cable that's connected to the card. When be put 3,3V to the card there is a current of about 900mA to the card, which is plenty when we expect at most 300mA. We would be very happy if anyone can give us some idea of what's wrong and/or how we can test our card to find the problem, or maybe how to reset the card completely. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148503
On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com> wrote: > > > Hi all, > > > This is a post to announce the existence of theAjarDSPproject, an > > attempt to design and implement an open source VLIW DSP with an open > > source tool chain (assembler, simulator/debugger and C compiler). > > > Check out the details at:http://code.google.com/p/ajardsp/ > > This sounds very interesting. I have contemplated doing something similar > a long time as there were no FPGA optimized DSP processor available that > I'm was aware of, but in the end I got stuck creating a fairly general > purpose FPGA optimized processor instead. I agree, this is a very interesting subject and there does indeed seem to be a lack of open source DSP implementations available on the net. However, at this point in time I would not consider AjarDSP to be in any way FPGA optimized. It is approaching a feature complete phase and after that focus will naturally shift to trying to increase speed and reduce area. Somewhere inbetween it would also be interesting to evaluate the 'compiler friendliness' of certain architectural features... > > Are you doing this just for fun or do you have some specific applications > in mind? No, there is no specific application in mind except perhaps some demo in the area of audio processing. The goal for the project is simply to provide the DSP and the tools. In the end hopefully someone will find it useful and maybe consider it for use in some product. In the meantime I consider this CV improvement and of course I can't deny that it is quite fun to work on every now and then :) /MarkusArticle: 148504
Hello, I'm learning to use FPGA, and i've designed and realized some schematic using spartan-3 xc3s200 (208 pin) and xcf01s, the last following UG332.pdf pag 68. I'm using the xilinx ise 9.2 updated sp4, and a digilent programmer like xilinx programmer. In impact, the .bit and the mcs file was correctly created, and I can program both devices without problems or error messages. In particular, I can create the .mcs file for the flash, I can program that, but when I turn off the power the FPGA can't load from the flash. I can program directly the flash and the program work well obviously until I turn off the power. I tried to see the signal CCLK (pin 104) with a scope but the signal was always high (I dont't see the 6Mhz clock..) I've set the CCLK option in fpga startup option, and (6 default) as configuration rate. I tryed to put to ground the pin 7 of XCF01S (cf connected to pin 207 of the xc3s200) but never happened. I've realized two schematic and both have the same problem. on the last schematic I've pulled high (2.5V) with a 4.7k resistor the prog_b, init_b pins, and to 3.3V with a 330 ohm the done pin. the other schematic links are: (flash)vcco = vccj = vccint = 3.3V (fpga)M0,M1,M2,HSWAP_EN = ground (flash)reset <-->(fpga)init_b (flash)CF <--->(fpga)prog_b (flash(D0)<--->(fpga)din (flash(tdi)<--->(fpga)tdo (flash)clk <--->(fpga)cclk (flash)tdo <--->(programmer)tdo (programmer)tms <--->(flash)tms (flash)tms <--->82ohm <--->tms (programmer)tck <--->(flash)tck (flash)tck) <---> 82ohm <---> (fpga)tck (programmer)tdi <---> 82ohm <---> (fpga)tdi (programmer)vref <---> 3.3V please, could you help me? thank you very much and regards. andrea francovich --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148505
On Jul 28, 8:40=A0am, Markus Lavin <markusl.se78pleasenos...@gmail.com> wrote: > On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > > > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com> wrote: > > > > Hi all, > > > > This is a post to announce the existence of theAjarDSPproject, an > > > attempt to design and implement an open source VLIW DSP with an open > > > source tool chain (assembler, simulator/debugger and C compiler). > > > > Check out the details at:http://code.google.com/p/ajardsp/ > > > This sounds very interesting. I have contemplated doing something simil= ar > > a long time as there were no FPGA optimized DSP processor available tha= t > > I'm was aware of, but in the end I got stuck creating a fairly general > > purpose FPGA optimized processor instead. > > I agree, this is a very interesting subject and there does indeed seem > to be a lack of open source DSP implementations available on the net. > However, at this point in time I would not consider AjarDSP to be in > any way FPGA optimized. It is approaching a feature complete phase and > after that focus will naturally shift to trying to increase speed and > reduce area. Somewhere inbetween it would also be interesting to > evaluate the 'compiler friendliness' of certain architectural > features... > > > > > Are you doing this just for fun or do you have some specific applicatio= ns > > in mind? > > No, there is no specific application in mind except perhaps some demo > in the area of audio processing. The goal for the project is simply to > provide the DSP and the tools. In the end hopefully someone will find > it useful and maybe consider it for use in some product. In the > meantime I consider this CV improvement and of course I can't deny > that it is quite fun to work on every now and then :) > > /Markus Why did you want to provide a VLIW DSP processor? Did you have any specific goals in mind? VLIW devices have problems with bandwidth to external memory which can limit the ultimate speed of the processor. Of course many apps and/or the key portions of apps can be put in internal memory to run at full speed, but again a VLIW processor has a limitation, program memory usage. The program code tends to be very large which can eat up internal memory quickly. Why go with a VLIW when a more conventional processor can do most jobs very well? It could be very interesting to use the dual port feature of internal FPGA memory to allow two DSPs to share one instruction space. They can be executing the code independently, but the code storage would be half. In FPGAs with limited memory, this can be important. RickArticle: 148506
On Jul 28, 7:47=A0am, Eyyub Can Odacioglu <ecodacio...@gmail.com> wrote: > How can I solve this error? > > ERROR:Pack:1107 - Unable to combine the following symbols into a > single IOB > =A0 =A0component: > =A0 =A0 =A0 =A0 BUF symbol "TXD_OBUF" (Output Signal =3D TXD) > =A0 =A0 =A0 =A0 PAD symbol "TXD" (Pad Signal =3D TXD) > =A0 =A0Each of the following constraints specifies an illegal physical > site for a > =A0 =A0component of type IOB: > =A0 =A0 =A0 =A0 Symbol "TXD" (LOC=3DR7) > =A0 =A0Please correct the constraints accordingly. > > E.Can ODACIOGLU Get out the datasheet for your part. What type of pin is location R7? If it is not an I/O pin (i.e. input only or special purpose pin) you can't use it as an output pin. Regards, GaborArticle: 148507
On Jul 27, 8:43=A0pm, Richard <Richard.Gran...@hotmail.com> wrote: > Hi, > > I wanna get started to design architectures with partially > reconfiguarable modules. I am using a Virtex-5, according > to the manual this board now also allows to dyanmically > change the clock using the DRP port. The way to implement > partially reconfigurable logic blocks seems to be described > in this document: > > http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/ug7... > > I assume this is the state-of-the-art since it has been recently > purchased. I am wondering if somebody has maybe additional ressources > that are helpful to get started with this topic. In particular a very > simple would be very helpful to get a deeper insight how it works. > > The ultimate goal is then to have a design the partially changes > it reconfiguration depending on the input. Silly question: From where > will the partial modules be loaded? From Flash or are the somehow > requested over the JTAG interface when they are required? > > Many thanks for your help, > Rich Don't confuse "Dynamic" and "Partial" configuration. They mean two different things (at least to Xilinx). The DRP is a bus that lets you program the DCM and other hard IP blocks inside the V5 from your other fabric logic. Partial reconfiguration uses the JTAG or parallel configuration ports. This is more like configuring the entire part but it only affects a portion of the chip. The hardest part of achieving this is partitioning the design so that a portion of the chip can be re-used without breaking the remaining running design. HTH, GaborArticle: 148508
On Jul 28, 11:52=A0am, "andfn" <andfn@n_o_s_p_a_m.libero.it> wrote: > Hello, I'm learning to use FPGA, and i've designed and realized some > schematic > using spartan-3 xc3s200 (208 pin) and xcf01s, the last following UG332.pd= f > pag 68. > > I'm using the xilinx ise 9.2 updated sp4, and a digilent programmer > like xilinx programmer. > > In impact, the .bit and the mcs file was correctly created, and I can > program > both devices without problems or error messages. > > In particular, I can create the .mcs file for the flash, I can program > that, but when I turn off the power the FPGA can't load from the > flash. > > I can program directly the flash and the program work well obviously unti= l > I turn off the power. > > I tried to see the signal CCLK (pin 104) with a scope but the signal was > always high (I dont't see the 6Mhz clock..) > > I've set the CCLK option in fpga startup option, and (6 default) as > configuration rate. > > I tryed to put to ground the pin 7 of XCF01S (cf connected to pin 207 of > the xc3s200) but never happened. > > I've realized two schematic and both have the same problem. > > on the last schematic I've pulled high (2.5V) with a 4.7k resistor the > prog_b, init_b pins, and to 3.3V with a 330 ohm the done pin. > > the other schematic links are: > > (flash)vcco =3D vccj =3D vccint =3D 3.3V > > (fpga)M0,M1,M2,HSWAP_EN =3D ground > > (flash)reset <-->(fpga)init_b > (flash)CF <--->(fpga)prog_b > (flash(D0)<--->(fpga)din > (flash(tdi)<--->(fpga)tdo > (flash)clk <--->(fpga)cclk > > (flash)tdo <--->(programmer)tdo > > (programmer)tms <--->(flash)tms > (flash)tms <--->82ohm <--->tms > > (programmer)tck <--->(flash)tck > (flash)tck) <---> 82ohm <---> (fpga)tck > > (programmer)tdi <---> 82ohm <---> (fpga)tdi > > (programmer)vref <---> 3.3V > > please, could you help me? thank you very much and regards. > > andrea francovich > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You don't really need much to be running to get a CCLK from the FPGA. Check that your mode pins (M0 M1 M2) are really low - if you use a resistor to ground these it should be less than 1K Ohms. Other than that you need all power supplies (being able to program via JTAG seems to confirm these), and proper handling (pullups) on the PROG_B and INIT_B pins. There are some cases where the power-on sequence of supplies can affect configuration. These are covered in ug332. In any case pulling the PROG_B pin low momentarily should start the configuration even if there are power sequencing issues. So my top bet would be the mode pins. HTH, GaborArticle: 148509
On Jul 28, 1:06=A0pm, rickman <gnu...@gmail.com> wrote: > On Jul 28, 8:40=A0am, Markus Lavin <markusl.se78pleasenos...@gmail.com> > wrote: > > > > > On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > > > > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com> wrot= e: > > > > > Hi all, > > > > > This is a post to announce the existence of theAjarDSPproject, an > > > > attempt to design and implement an open source VLIW DSP with an ope= n > > > > source tool chain (assembler, simulator/debugger and C compiler). > > > > > Check out the details at:http://code.google.com/p/ajardsp/ > > > > This sounds very interesting. I have contemplated doing something sim= ilar > > > a long time as there were no FPGA optimized DSP processor available t= hat > > > I'm was aware of, but in the end I got stuck creating a fairly genera= l > > > purpose FPGA optimized processor instead. > > > I agree, this is a very interesting subject and there does indeed seem > > to be a lack of open source DSP implementations available on the net. > > However, at this point in time I would not consider AjarDSP to be in > > any way FPGA optimized. It is approaching a feature complete phase and > > after that focus will naturally shift to trying to increase speed and > > reduce area. Somewhere inbetween it would also be interesting to > > evaluate the 'compiler friendliness' of certain architectural > > features... > > > > Are you doing this just for fun or do you have some specific applicat= ions > > > in mind? > > > No, there is no specific application in mind except perhaps some demo > > in the area of audio processing. The goal for the project is simply to > > provide the DSP and the tools. In the end hopefully someone will find > > it useful and maybe consider it for use in some product. In the > > meantime I consider this CV improvement and of course I can't deny > > that it is quite fun to work on every now and then :) > > > /Markus > > Why did you want to provide a VLIW DSP processor? =A0Did you have any > specific goals in mind? =A0VLIW devices have problems with bandwidth to > external memory which can limit the ultimate speed of the processor. > Of course many apps and/or the key portions of apps can be put in > internal memory to run at full speed, but again a VLIW processor has a > limitation, program memory usage. =A0The program code tends to be very > large which can eat up internal memory quickly. > > Why go with a VLIW when a more conventional processor can do most jobs > very well? =A0It could be very interesting to use the dual port feature > of internal FPGA memory to allow two DSPs to share one instruction > space. =A0They can be executing the code independently, but the code > storage would be half. =A0In FPGAs with limited memory, this can be > important. > > Rick Actually many VLIW processors work around the memory issue by compressing the code and un-compressing it as it gets loaded into cache. Granted they typically use more silicon resources than you would put into a typical FPGA design, but the compression algorithm doesn't need to be very sophisticated as the code word tends to be mostly zero (assuming active high function enable). Take a look at the NXP Nexperia series (formerly TriMedia). Regards, GaborArticle: 148510
JoSa wrote: > Me and my college are first time users of programming a FPGAs. We have > bought the already assembled card Xylo-L from knjn. It has a Spartan-3E > FPGA among other parts. Somewhere during the process of handling this card > something has gone wrong and now when we connect power to the card it gets > really hot fast. We can still put in some simple functions into the FPGA, > e.g. we can make a couple of LED glow and blink. This must mean that the > FPGA is not totally crashed. We have tested to reset the card with the USB > cable that's connected to the card. > When be put 3,3V to the card there is a current of about 900mA to the card, > which is plenty when we expect at most 300mA. > > We would be very happy if anyone can give us some idea of what's wrong > and/or how we can test our card to find the problem, or maybe how to reset > the card completely. You have probably had an ESD event and damaged one or several I/O pads on the FPGA. The rest of the FPGA may contin ue to work for a while. If this board has an EPROM to load the FPGA configuration, try to disable it or hold the PROG pin on the FPGA in the active state, preventing it from loading any config. If it still gets hot, it is most likely ESD damage. If it runs at normal current and doesn't get hot, then your program may be clocking at excessive rates or causing contention within the chip or on I/O pins. JonArticle: 148511
On Jul 27, 11:30=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 27 Jul., 09:57, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > > Andrew Feldhaus <Re...@thread.pls> writes: > > > Hi, > > > > As I understand it, good practice dictates that in a synthesis-target= ed > > > setting, components should use ports of type std_logic or std_logic_v= ector > > > only. > > Why? > Todays FPGAs don't even have tristate buffers internally so STD_ULOGIC > is clearly more > appropriate than STD_LOGIC. > It simulates faster and there are bugs that can be found by the > synthesis tools earlier in the > build process (i.e. signals with multiple drivers) > > SIGNED and UNSIGNED are subtypes of STD_LOGIC, so there should be no > issue whatsoever > in synthesizing them. > > Some synthesis tools throw away the type information when creating > timing simulation models > and replace them with STD_LOGIC which clearly is a bug of the tools. > It is very easy to write a Perl script that puts the type information > back in so there plainly is no excuse > for the tools to do that. > > Kolja I was giving consideration to using STD_ULOGIC, but I actually mostly use signed and unsigned for vectors and I believe they are implemented as subtypes of std_logic_vector, no? So I could use STD_ULOGIC for the control signals, but my buses would still essentially be STD_LOGIC. Would that really speed up my simulations much? I do appreciate the superior bug catching of using STD_ULOGIC, that is why I was thinking about changing my default type. But I am concerned that the conversion routines in numeric_std won't work with STD_ULOGIC and I would have to add yet another layer of conversion text. VHDL is already wordy, I hate to add to that. RickArticle: 148512
On Jul 28, 1:48=A0pm, Gabor <ga...@alacron.com> wrote: > On Jul 28, 1:06=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On Jul 28, 8:40=A0am, Markus Lavin <markusl.se78pleasenos...@gmail.com> > > wrote: > > > > On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > > > > > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com> wr= ote: > > > > > > Hi all, > > > > > > This is a post to announce the existence of theAjarDSPproject, an > > > > > attempt to design and implement an open source VLIW DSP with an o= pen > > > > > source tool chain (assembler, simulator/debugger and C compiler). > > > > > > Check out the details at:http://code.google.com/p/ajardsp/ > > > > > This sounds very interesting. I have contemplated doing something s= imilar > > > > a long time as there were no FPGA optimized DSP processor available= that > > > > I'm was aware of, but in the end I got stuck creating a fairly gene= ral > > > > purpose FPGA optimized processor instead. > > > > I agree, this is a very interesting subject and there does indeed see= m > > > to be a lack of open source DSP implementations available on the net. > > > However, at this point in time I would not consider AjarDSP to be in > > > any way FPGA optimized. It is approaching a feature complete phase an= d > > > after that focus will naturally shift to trying to increase speed and > > > reduce area. Somewhere inbetween it would also be interesting to > > > evaluate the 'compiler friendliness' of certain architectural > > > features... > > > > > Are you doing this just for fun or do you have some specific applic= ations > > > > in mind? > > > > No, there is no specific application in mind except perhaps some demo > > > in the area of audio processing. The goal for the project is simply t= o > > > provide the DSP and the tools. In the end hopefully someone will find > > > it useful and maybe consider it for use in some product. In the > > > meantime I consider this CV improvement and of course I can't deny > > > that it is quite fun to work on every now and then :) > > > > /Markus > > > Why did you want to provide a VLIW DSP processor? =A0Did you have any > > specific goals in mind? =A0VLIW devices have problems with bandwidth to > > external memory which can limit the ultimate speed of the processor. > > Of course many apps and/or the key portions of apps can be put in > > internal memory to run at full speed, but again a VLIW processor has a > > limitation, program memory usage. =A0The program code tends to be very > > large which can eat up internal memory quickly. > > > Why go with a VLIW when a more conventional processor can do most jobs > > very well? =A0It could be very interesting to use the dual port feature > > of internal FPGA memory to allow two DSPs to share one instruction > > space. =A0They can be executing the code independently, but the code > > storage would be half. =A0In FPGAs with limited memory, this can be > > important. > > > Rick > > Actually many VLIW processors work around the memory issue by > compressing the code and un-compressing it as it gets loaded into > cache. =A0Granted they typically use more silicon resources than > you would put into a typical FPGA design, but the compression > algorithm doesn't need to be very sophisticated as the code word > tends to be mostly zero (assuming active high function enable). > > Take a look at the NXP Nexperia series (formerly TriMedia). > > Regards, > Gabor Hmmm... that sounds to me like the instructions are stored in external memory and the instruction decode is being done when the code is fetched from external memory and the cache is actually real time updated micro-code. But then I guess that is what VLIW is, pre- decoded instructions. I worked with an array processor (a double rack cabinet sized DSP chip) which was microcoded. There was no instruction level, it was all microcode. So in essence, it was a VLIW DSP processor... that required 230 VAC power and its own AC to cool it! RickArticle: 148513
On Jul 28, 7:05=A0pm, rickman <gnu...@gmail.com> wrote:
> On Jul 27, 11:30=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
> I was giving consideration to using STD_ULOGIC, but I actually mostly
> use signed and unsigned for vectors and I believe they are implemented
> as subtypes of std_logic_vector, no? =A0
No, they are implemented as arrays of std_logic. Signed, unsigned and
std_logic_vector have exactly the same definition...
type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
type SIGNED is array (NATURAL range <>) of STD_LOGIC;
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;
Even though they have the same definition, because they are declared
as *type* and not *subtype* it means that you can't just assign
something of one type to something else of another. From earlier
posts, I know that this is a gripe of yours, but that's the way strong
type checking works.
> I do appreciate the superior bug catching of using STD_ULOGIC, that is
> why I was thinking about changing my default type. =A0But I am concerned
> that the conversion routines in numeric_std won't work with STD_ULOGIC
> and I would have to add yet another layer of conversion text.
There aren't any *extra* conversions caused by using std_ulogic versus
std_logic, you will have to change some existing conversions
though....
Instead of this:
Some_slv_sig <=3D std_logic_vector(Some_unsigned);
Do this
Some_slv_sig <=3D std_ulogic_vector(Some_unsigned);
Kevin Jennings
Article: 148514On Jul 27, 11:30=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > SIGNED and UNSIGNED are subtypes of STD_LOGIC, Not quite...the definitions are: type UNSIGNED is array (NATURAL range <>) of STD_LOGIC; type SIGNED is array (NATURAL range <>) of STD_LOGIC; TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic; Kevin JenningsArticle: 148515
On 29 Jul., 02:34, KJ <kkjenni...@sbcglobal.net> wrote: > Instead of this: > =A0 =A0 Some_slv_sig <=3D std_logic_vector(Some_unsigned); > Do this > =A0 =A0 Some_slv_sig <=3D std_ulogic_vector(Some_unsigned); a package numeric_unresolved would be nice.... KoljaArticle: 148516
how does a host know a usb3.0 device get attached?what kind of reset will the host give on detecting the device --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148517
As a newbie I'm working on an SDR SDRAM controller in VHDL and looking at datasheet of the chip I read how to set CAS latency to 2. I'm just using only simple READA/WRITA (with autoprecharge) commands avoiding refresh/autorefresh ones. My answer is simple, Does "AutoPrecharged" commands (READA/WRITA) issue dram refresh also avoiding me to performs ALSO the refresh command? I've looked at OneChip MSX SDRAM controller and refresh command is used only during initialization ... Thanks in advance for any help! Saverio --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148518
You need to send refresh commands at the period it gives in the data sheet. It will be something like every 7.8 us. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148519
On Jul 29, 7:05=A0am, "siriokds" <siriokds@n_o_s_p_a_m.gmail.com> wrote: > As a newbie I'm working on an SDR SDRAM controller in VHDL and looking at > datasheet of the chip I read how to set CAS latency to 2. > I'm just using only simple READA/WRITA (with autoprecharge) commands > avoiding refresh/autorefresh ones. > > My answer is simple, > > Does "AutoPrecharged" commands (READA/WRITA) issue dram refresh also > avoiding me to performs ALSO the refresh command? > > I've looked at OneChip MSX SDRAM controller and refresh command is used > only during initialization ... > > Thanks in advance for any help! > > Saverio > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Precharge and refresh are two different things. You can think of a row of memory haveing two operating states, Active, and Precharged. Issuing a row activate command places the row in the active state. Issuing a precharge comand or using a read or write with autoprecharge places the row in the precharged state. The row must be active to perform read or write. All rows must be precharged before issuing auto-refresh commands. For SDR SDRAM you don't necessarily have to issue refresh at a constant rate because it doesn't have a DLL like the DDR parts. However you must meet the refresh rule that all rows are refreshed within the refresh period specified, usually 32 ms or 64 ms. This generally works out to an average of one auto-refresh command every 15.6 us for smaller parts or every 7.8 us for the larger ones. Also for SDR SDRAM (but not DDR) you can effectively refresh the part by performing row activates to all rows within the refresh period. Note that row activate works on one bank at a time, while auto-refresh works on all four banks at once. So in effect it takes four times as many row activates to refresh the part. However there are some applications like video buffer memory where this much access would occur anyway and then you can avoid using refresh commands altogether. If the controller you looked at doesn't perform auto-refresh cycles after initialization, it should either have a way to request a refresh cycle once it is operational, or have some other method of making sure all rows get refreshed (some controllers do "scrubbing" refresh consisting of reading out data, performing error correction, and writing it back). I seem to recall that Fujitsu had a good data sheet that showed a state diagram of the SDRAM. But it's been a while since I first looked at these parts and the whole thing has become ingrained in my head since then. HTH, GaborArticle: 148520
The other place you can ask question and get more information is the HD Xilinx Forum. http://forums.xilinx.com/t5/Hierarchical-Design/bd-p/Hier_Des There is also a new PR Video here: http://www.xilinx.com/products/design_resources/design_tool/resources/index.htm I am not a PR expert so I can't answer your question but I do think there are several different ways to get the new configuration loaded into the FPGA device. Kate --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148521
On Jul 29, 6:43=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 29 Jul., 02:34, KJ <kkjenni...@sbcglobal.net> wrote: > > > Instead of this: > > =A0 =A0 Some_slv_sig <=3D std_logic_vector(Some_unsigned); > > Do this > > =A0 =A0 Some_slv_sig <=3D std_ulogic_vector(Some_unsigned); > > a package numeric_unresolved would be nice.... > > Kolja Why do you think a numeric_unresolved would help with anything? The type conversions come about because of converting to/from std_logic types, not because the conversion is to/from resolved (or not resolved) data types. KJArticle: 148522
I am working on a project where I need to implement 6-th order Butterworth low-pass filters in an FPGA. In some the bandwidth is low relative to the input data rate, whereas others have higher bandwidth. I can use ScopeIIR or Matlab to give me a good idea of coefficient accuracy for any given ratio of bandwidth to input sample rate. However, I'm not sure what data-path accuracy I need (for 20-bit input / output accuracy). Is there a rule-of-thumb I can use, or do I just have to simulate the filter with real data and see what gives me low enough noise? I was planning on using biquads, but I'm not sure whether I'm better off with DF1 or DF2 sections. Thoughts? Thanks PeteArticle: 148523
Pete Fraser wrote: > I am working on a project where I need to > implement 6-th order Butterworth low-pass > filters in an FPGA. In some the bandwidth is > low relative to the input data rate, whereas > others have higher bandwidth. I can use ScopeIIR > or Matlab to give me a good idea of coefficient > accuracy for any given ratio of bandwidth to > input sample rate. > > However, I'm not sure what data-path accuracy > I need (for 20-bit input / output accuracy). > Is there a rule-of-thumb I can use, or do I just > have to simulate the filter with real data and > see what gives me low enough noise? > > I was planning on using biquads, but I'm not sure > whether I'm better off with DF1 or DF2 sections. If the filter cutoff frequency is much lower then samplerate, then loss of precision in the direct implementation of the biquad section could be very roughly estimated as ~ Q (Fc/Fs)^2. Let's say Fc = 100 kHz, Fs = 100 Hz, Q = 1. Loss of precision ~ 1e6 ~ 20 bits. That is, if your filter is implemented with 32 bit data path, the result will be accurate only to 12 bits. There are, of course, methods to get more accurate estimates and to improve precision, however this is a different and rather long story. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.comArticle: 148524
Pete Fraser <pfraser@covad.net> wrote: >I am working on a project where I need to >implement 6-th order Butterworth low-pass >filters in an FPGA. In some the bandwidth is >low relative to the input data rate, whereas >others have higher bandwidth. I can use ScopeIIR >or Matlab to give me a good idea of coefficient >accuracy for any given ratio of bandwidth to >input sample rate. > >However, I'm not sure what data-path accuracy >I need (for 20-bit input / output accuracy). >Is there a rule-of-thumb I can use, or do I just >have to simulate the filter with real data and >see what gives me low enough noise? You should simulate the fixed-point filter. When simulating, you do not necessarily have to stimulate it with realistic data. I often will stimulate the design being tested with bandlimited noise, and measure the RMS error of output (relative to the same design, but in full floating-point). Plotting the RMS error (in dBc) vs. RMS input level gives you a very good idea of the dynamic range of the fixed point design. >I was planning on using biquads, but I'm not sure >whether I'm better off with DF1 or DF2 sections. You can do this, or you can use a lattice topology (called "ARMA" in matlab/fdatool), which is the most well-behaved topology. Steve
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