Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 131850

Article: 131850
Subject: Re: FPGA Processor for Signal Processing ?
From: morphiend <morphiend@gmail.com>
Date: Sun, 4 May 2008 06:39:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 3, 11:18 am, HansWernerMarsc...@web.de wrote:
> You find at the web and in books implementations of processors for FPGA
> =B4s and also processors like Picoblaze and Microblaze from firms like
> Xilinx. Are there also implementations of processors special designed
> for signal processing that realize things like FFT for example ?
>
> Thanks for help

If you're performing signal processing, straight FPGA logic is more
suited to this than using the resources to instantiate a general
purpose processor with built-in DSP extensions. Since most signal
processing applications can be performed in parallel, this can be
exactly realized in the FPGA fabric rather than attempted by having
"very fast" computational pipelines in a DSP processor.

If you are hard pressed on having a GPP, then why not look at DSP co-
processors to perform the functions you're looking for: FFT, L/HPF,
etc. Depending on the base architecture you start with you have
options like using the FSL on the Microblaze to have a low-latency
communication interface, or the ports on the Picoblaze. Although,
depending on the algorithm(s) you are planning on running it may be
difficult to get by with the standard Picoblaze because of its limited
instruction memory.

-- Mike

Article: 131851
Subject: Re: FPGA Processor for Signal Processing ?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 04 May 2008 14:50:47 +0100
Links: << >>  << T >>  << A >>
On Sat, 3 May 2008 08:18:33 -0700 (PDT), HansWernerMarschke@web.de wrote:

>You find at the web and in books implementations of processors for FPGA
>´s and also processors like Picoblaze and Microblaze from firms like
>Xilinx. Are there also implementations of processors special designed
>for signal processing that realize things like FFT for example ?

Yes and no. There are certainly components which realize FFT only, or FIR filter
only, etc. But I don't know of any "DSP oriented" CPU blocks. I believe these
would typically be larger than Microblaze etc, and typically much slower than a
pure FFT component. Therefore they would usually give you the worst of both
worlds.

The effort spent generating optimal code for such a DSP engine is probably
better spent generating optimal hardware to realize the same function; you are
likely to gain a lot in performance.

(I realize there are probably exceptions to this principle, but my perception is
they are relatively small niches).

- Brian

Article: 131852
Subject: Re: Using SRL16 with reset
From: austin <austin@xilinx.com>
Date: Sun, 04 May 2008 07:45:32 -0700
Links: << >>  << T >>  << A >>
Alain,

Yes, that is a neat feature (allow a set or reset with small overhead 
while still using SRL), however I have seen a thread where it isn't 
working as intended for some cases.  There is a CR filed on it, so we 
will see if it is a real bug, or a weird corner case (which still needs 
to get fixed).

Automatic use of SRL16(and/or SRL64 in V5) by the synthesis tool is not 
consistent as third party tools don't always make the many cases where 
the SRL is advantageous a priority.  XST pioneers the use, so we may 
then show third parties how we did it (and give it to them).

Austin

Article: 131853
Subject: Re: Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
From: Bob <rsg.uClinux@gmail.com>
Date: Sun, 4 May 2008 07:50:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 2, 11:34 pm, "MM" <mb...@yahoo.com> wrote:

> I guess Antti is right... Anyway, which version of the tools are you using?
9.2i

> What is you microcontroller?
Freescale MCF5234 Coldfire

> Do you have any external pullups?
No.

> Do you disconnect the cable when running your player?
Yes

> There is a number of Answer Records on Xilinx site, which might be relevant to your problem.
> e.g.http://www.xilinx.com/support/answers/22255.htm
I've looked, but I can't seem to find one that helps...

I need to get this working by Friday, so I hope someone has some
ideas?

Thanks,
-Bob

Article: 131854
Subject: need recommendation for PCB fab & BGA assembly vendor, I'm in SF bay area
From: "fpganut" <rats@myhouse.com>
Date: Sun, 4 May 2008 08:50:41 -0700
Links: << >>  << T >>  << A >>
Hi.

Does anyone have recommendations for a pcb fab vendor and an assembly vendor 
?
Preferably the same vendor but ok if not. This is for just a few small 
boards, 6-8 layers,
a couple of FPGAs in bga package.

I'm looking for quality 1st & price 2nd. Don't want any bad coonections on 
some power
& gnd balls.  Thanks

Jim 



Article: 131855
Subject: Re: Using SRL16 with reset
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 04 May 2008 18:18:33 GMT
Links: << >>  << T >>  << A >>
austin <austin@xilinx.com> wrote:

>Alain,
>
>Yes, that is a neat feature (allow a set or reset with small overhead 
>while still using SRL), however I have seen a thread where it isn't 
>working as intended for some cases.  There is a CR filed on it, so we 
>will see if it is a real bug, or a weird corner case (which still needs 
>to get fixed).
>
>Automatic use of SRL16(and/or SRL64 in V5) by the synthesis tool is not 
>consistent as third party tools don't always make the many cases where 
>the SRL is advantageous a priority.  XST pioneers the use, so we may 
>then show third parties how we did it (and give it to them).

Which version of XST supports this? I always infer SRL16 (and similar)
from primitives out of lazyness.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 131856
Subject: Re: Old FPGA question
From: whygee <whygee@yg.yg>
Date: Mon, 05 May 2008 00:04:13 +0200
Links: << >>  << T >>  << A >>
Nicolas Matringe wrote:
> whygee a =E9crit :
>> Don't ask me that, I'm just looking in the trash bin :-)
> Yann you'll have to tell me where this is ;-)

ok :-) my old f-cpu email address still works ;-P
Hint : it's in Paris.

btw, i checked my treasure : there are 57 reels
of resistors and about 30 of ceramic capacitors.
I'm riiich \o/ :-)
But i'll have to build a reel holder,
with all the wood that i have also found there :-)

then i'll have to etch a pair of PCB for the XCV400.

> Nicolas
yg

Article: 131857
Subject: EDK9.2i simulation problems.
From: chrisdekoh@gmail.com
Date: Sun, 4 May 2008 19:39:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

1)   I am having some EDK simulation problems. I am using EDK9.2i with
microblaze 7.
   I have attached a peripheral to the FSL bus using EDK's configure
coprocessor and written its corresponding drivers for the peripheral
which has commands like the one below. ie..

#include "mb_interface.h"

....
  microblaze_bwrite_fsl(data,0);



   I tried generating simulation libraries to test my drivers
interfacing with the attached peripheral. I created a test bench
system_tb which would instantiate system.vhd. In addition, I had also
added the following lines:

configuration system_tb_conf of system_tb is
  for all
     for all : system use configuration work.system_conf;
     end;
  end for;
end system_tb_conf;

to ensure that the initialised BRAM by data2mem is picked up correctly
with the command:

vsim -t ps system_tb_conf

. I have also ensured that microblaze + its peripherals do come out of
resets correctly.

however, when I probe the FSL bus from the microblaze processor, only
data from FSL0_M_data has data. The write signals from FSL0_M_write
are never asserted. In addition, no other signals from the microblaze
driving the FSL bus is asserted.

Did I miss out anything? I have set up EDK for simulation before
whilst using EDK9.1i and have done exactly the same things to get the
simulation up and running. However, it just does not seem to work in
this case.

the system I am using is the default base from the xsb provided by
Avnet with the exception to the FSL buses which is required to link to
the peripheral. I am using FSL link 0.



thanks for your help in advance!

Chris

Article: 131858
Subject: Re: FPGA Processor for Signal Processing ?
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Mon, 5 May 2008 02:51:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-05-04, Brian Drummond <brian_drummond@btconnect.com> wrote:
> The effort spent generating optimal code for such a DSP engine is probably
> better spent generating optimal hardware to realize the same function; you are
> likely to gain a lot in performance.
>
> (I realize there are probably exceptions to this principle, but my perception is
> they are relatively small niches).

In principle I agree with you, but in practice I can see quite a few advantages
to an FPGA optimized DSP processor. Consider for example a video conference
application with DVD quality video and audio. You probably want to have custom
hardware for most of the video encoding and perhaps decoding as well. However,
I don't think there is any need for custom hardware for audio encoding/decoding.
But it might make sense to use a specialized DSP processor for that encoding and
decoding so that more CPU time is available for other parts of the system (part
of the video decoder for example).

So in this case, instead of making custom hardware for both video encoding/
decoding and audio encoding/decoding, a generic DSP processor block can be used
for many tasks. This will most probably reduce the total logic area and it will
certainly reduce the design time of the application.

/Andreas

Article: 131859
Subject: Re: EDK9.2i simulation problems.
From: "Göran Bilski" <goran.bilski@xilinx.com>
Date: Mon, 5 May 2008 10:45:54 +0200
Links: << >>  << T >>  << A >>
Hi,

It's hard to tell with so little information.

Did MicroBlaze get out of reset in the simulation?
Did MicroBlaze start to execute code from your application?

If MicroBlaze gets to the instruction that writes data to FSL, the only 
thing stopping it is if the fsl_full flag is asserted.

Göran

<chrisdekoh@gmail.com> wrote in message 
news:9ae5b725-6219-4ac9-b5ff-af7ce4d50df8@w1g2000prd.googlegroups.com...
> Hi
>
> 1)   I am having some EDK simulation problems. I am using EDK9.2i with
> microblaze 7.
>   I have attached a peripheral to the FSL bus using EDK's configure
> coprocessor and written its corresponding drivers for the peripheral
> which has commands like the one below. ie..
>
> #include "mb_interface.h"
>
> ....
>  microblaze_bwrite_fsl(data,0);
>
>
>
>   I tried generating simulation libraries to test my drivers
> interfacing with the attached peripheral. I created a test bench
> system_tb which would instantiate system.vhd. In addition, I had also
> added the following lines:
>
> configuration system_tb_conf of system_tb is
>  for all
>     for all : system use configuration work.system_conf;
>     end;
>  end for;
> end system_tb_conf;
>
> to ensure that the initialised BRAM by data2mem is picked up correctly
> with the command:
>
> vsim -t ps system_tb_conf
>
> . I have also ensured that microblaze + its peripherals do come out of
> resets correctly.
>
> however, when I probe the FSL bus from the microblaze processor, only
> data from FSL0_M_data has data. The write signals from FSL0_M_write
> are never asserted. In addition, no other signals from the microblaze
> driving the FSL bus is asserted.
>
> Did I miss out anything? I have set up EDK for simulation before
> whilst using EDK9.1i and have done exactly the same things to get the
> simulation up and running. However, it just does not seem to work in
> this case.
>
> the system I am using is the default base from the xsb provided by
> Avnet with the exception to the FSL buses which is required to link to
> the peripheral. I am using FSL link 0.
>
>
>
> thanks for your help in advance!
>
> Chris 



Article: 131860
Subject: Re: Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
From: =?ISO-8859-1?Q?Andreas_H=F6lscher?= <andreas.hoelscher@dsa-ac.de>
Date: Mon, 05 May 2008 16:30:30 +0200
Links: << >>  << T >>  << A >>
Bob, (04.05.2008 16:50):

>> Do you have any external pullups?
> No.
Did you check "Drive Done Pin High" in the startup options?

Andreas

Article: 131861
Subject: Re: Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
From: Bob <rsg.uClinux@gmail.com>
Date: Mon, 5 May 2008 07:47:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 5, 10:30 am, Andreas H=F6lscher <andreas.hoelsc...@dsa-ac.de>
wrote:
> Did you check "Drive Done Pin High" in the startup options?

Maybe, but I don't think so.  I thought of trying this, but I'm not
convinced it has anything to do with it.  DONE not going high is just
a convenient way to tell if the configuration was successful, as I
have it controlling an LED.  Furthermore, the configuration is not
"taking effect", and the FPGA remains unconfigured.

On the other hand, if this "option" is automatically applied by iMPACT
when it is doing an actual FPGA configuration, but it is not added to
the recorded .svf or .xsvf files, then you may be right.  So, I will
try it tonight (~8:30 PM EDT), and let you all know.

In the meantime, in seems there are a number of potential "gotchas"
with various options that may be applied to the bit file generation
process.  Or to put it another way, I've become quite concerned that
I'm missing some critical options that may well be documented
somewhere and I messed it, or perhaps something everyone assumes I
know when in reality I don't.  Can someone who has done this give me a
concise list of options they used, or what options are critical, or
can point me to documentation on this (other then XAPP058)?  Whatever
is easy - I'm not asking for anything fancy.

Thanks!
-Bob


Article: 131862
Subject: Re: Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 5 May 2008 12:06:20 -0400
Links: << >>  << T >>  << A >>
"Bob" <rsg.uClinux@gmail.com> wrote in message 
news:286aab22-ec7d-4c46-b232-049bd306e451@a23g2000hsc.googlegroups.com...
> On May 2, 11:34 pm, "MM" <mb...@yahoo.com> wrote:
>
>> Do you have any external pullups?
> No.

I am not sure if this could be your problem, but... normally JTAG signals 
require pullups. Bitgen can (and probably does) enable them internally, but 
personally I've never relied upon them and always designed in external 
resistors... The behaviour with iMPACT might be different because there 
might be some pullups inside of the programming cable and/or simply the 
drivers/receivers are different.


/Mikhail







Article: 131863
Subject: Re: Forking in One-Hot FSMs
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Mon, 5 May 2008 09:13:07 -0700
Links: << >>  << T >>  << A >>
> You'll also find that changes (like switching the Nobl SRAM to DRAM as an 
> example) can be accomodated without having to change *everything*.

That has been on my mind because there is a DRAM on my board. Not only
will the DRAM require more cycles but perhaps too a varying number of
cycles depending on the sequentiality or randomness of the addressing.

I have seen controllers on the Xilinx site, but nothing, that talks about
several ports, and how the hand shaking is handled. My FAE has said that
some multiport examples are availble.

Brad Smallridge
AiVision





Article: 131864
Subject: Re: NIOS II CFI interface
From: ghelbig@lycos.com
Date: Mon, 5 May 2008 11:06:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 8:59 pm, "bjzhan...@gmail.com" <bjzhan...@gmail.com> wrote:
> On 5=D4=C21=C8=D5, =CF=C2=CE=E711=CA=B140=B7=D6, ghel...@lycos.com wrote:
>
> > On May 1, 2:27 am, "bjzhan...@gmail.com" <bjzhan...@gmail.com> wrote:
>
> > > Hi,everybody,I am a fresher of NIOSII,and in the passed days ,I have
> > > been familar with the nios II system,also write some test program
> > > about the gpio,timer,uart and can work properly,today I add the flash
> > > controoler(CFI),but it doesn't work.And I use the signal tap to watch
> > > the wave and the address bus is active but the read,write and cs is
> > > always '1',I don't know why,can someone give me some advice and debug
> > > methods.
>
> > Here are two helpful links:
> > <http://www.google.com/search?q=3Ddebug+nios>
> > <http://www.google.com/search?q=3Dsimulate+nios>
>
> > Here's something to read while you're trying to figure out how to use
> > google's search feature:
> > <http://www.altera.com/literature/an/an351.pdf>
>
> > You really should learn about Google's search feature; it works pretty
> > well.  And it's free for google-mail users (such as yourself), and the
> > rest of the internet.
>
> > Cheers,
> > G.
>
> Thanks,I have tried all what you say 2 days before and I have no idear
> so I refer to Google group for help.Now I know why,Firstly,the flash
> chip I use is not support CFI.but the nios II only support CFI
> compliant flash.Secondly,because the jtag uart also use jtag ,so if I
> use printf function and from the signal tap the signal I watch is
> always '1',I  remove the printf function and then the signal is active
> in the signal tap.

NIOS supports many types of NOR flash, and adding a new type is
usually a software change in the HAL.  If you're trying to use NAND
flash, there are application notes for those.

You can use a 'traditional' UART instead of the JTAG UART.  Several
design examples for this on the Altera web site.

Keep googleing,
G.



Article: 131865
Subject: Re: Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
From: Martin Darwin <martin.darwin.nospam@alcatel-lucent.com>
Date: Mon, 05 May 2008 14:48:20 -0400
Links: << >>  << T >>  << A >>

Bob wrote:
> In the meantime, in seems there are a number of potential "gotchas"
> with various options that may be applied to the bit file generation
> process.  Or to put it another way, I've become quite concerned that
> I'm missing some critical options that may well be documented
> somewhere and I messed it, or perhaps something everyone assumes I
> know when in reality I don't.  Can someone who has done this give me a
> concise list of options they used, or what options are critical, or
> can point me to documentation on this (other then XAPP058)?  Whatever
> is easy - I'm not asking for anything fancy.
> 
> Thanks!
> -Bob
> 

I have used XAPP058 to get a working setup. The only thing I struggled 
with was getting the DONE pin to go high. I belive the code has two 
options for the "RUNTEST" SVF instruction (or something like that): one 
is a delay loop and the other puts out clocks. Make sure you pick the 
code that puts out the clocks. The delay loop won't work. This was for a 
Spartan3A FPGA.

MD

Article: 131866
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 5 May 2008 13:09:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
The quadrature encoder has been tested and proven to work ( thank you,
Ken Chapman), detecting every transition as a count pulse, never an
accumulated error. The only flaw is a one-pulse backlash. That means,
it does not recognize the first change after a reversal of direction.
You could call it hysteresis, analogous to a +/- 1 count ambiguity,
known to exist in many conversions.
Peter Alfke

Below is the vhdl file, courtesy of my friend Ken Chapman:

 
----------------------------------------------------------------------------------------------------------------------------------
 -- Shaft Encoder
 
----------------------------------------------------------------------------------------------------------------------------------
 --
 -- Interface to rotary encoder.
 -- Detection of movement and direction.
 --
 -- The rotary switch contacts are filtered using their offset (one-
hot) style to
 -- clean them. Circuit concept by Peter Alfke.
 -- Note that the clock rate is fast compared with the switch rate.
 --

 rotary_filter: process(clk)
 begin
   if clk'event and clk='1' then

     --Synchronise inputs to clock domain using flip-flops in input/
output blocks.
     rotary_a_in <= rotary_a;
     rotary_b_in <= rotary_b;

     --concatinate rotary input signals to form vector for case
construct.
     rotary_in <= rotary_b_in & rotary_a_in;

     case rotary_in is

       when "00" => rotary_q1 <= '0';
                    rotary_q2 <= rotary_q2;

       when "01" => rotary_q1 <= rotary_q1;
                    rotary_q2 <= '0';

       when "10" => rotary_q1 <= rotary_q1;
                    rotary_q2 <= '1';

       when "11" => rotary_q1 <= '1';
                    rotary_q2 <= rotary_q2;

       when others => rotary_q1 <= rotary_q1;
                      rotary_q2 <= rotary_q2;
     end case;

   end if;
 end process rotary_filter;

 --
 -- Pipeline the valies of q1 and q2 so that we can detect ANY changes
and determine what changed.
 --
 -- The detection of any change is considered a rotation event.
 --
 -- Then the direction of rotation in one direction is indicated
by.....
 --    q1 changing from Low to High when q2 is Low
 --       or
 --    q1 changing from High to Low when q2 is High
 --       or
 --    q2 changing from Low to High when q1 is High
 --       or
 --    q2 changing from High to Low when q1 is Low
 --
 -- Clearly if neither of the above are true then the rotation was in
the opposite direction.
 --

 shaft_direction: process(clk)
 begin
   if clk'event and clk='1' then

     delay_rotary_q1 <= rotary_q1;
     delay_rotary_q2 <= rotary_q2;

     rotary_event <= (rotary_q1 xor delay_rotary_q1) or (rotary_q2 xor
delay_rotary_q2);

     rotary_right <=   ( (not delay_rotary_q1) and      rotary_q1  and
(not rotary_q2) )
                    or (      delay_rotary_q1  and (not rotary_q1)
and      rotary_q2  )
                    or ( (not delay_rotary_q2) and      rotary_q2
and      rotary_q1  )
                    or (      delay_rotary_q2  and (not rotary_q2) and
(not rotary_q1) );


   end if;
 end process shaft_direction;

 --
 --
 -- A simple binary counter is used to record directional change
 --   LEFT decrements counter.
 --   RIGHT increments counter.
 --

 position_counter: process(clk)
 begin
   if clk'event and clk='1' then
     if rotary_event = '1' then
       if rotary_right = '1' then
         rotate_counter <= rotate_counter + 1;
        else
         rotate_counter <= rotate_counter - 1;
       end if;
     end if;
   end if;
 end process position_counter;

 --
 
----------------------------------------------------------------------------------------------------------------------------------
 --
 --

end Behavioral;

------------------------------------------------------------------------------------------------------------------------------------
--
-- END OF FILE shaft_encoder.vhd


Article: 131867
Subject: Re: Forking in One-Hot FSMs
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 5 May 2008 13:35:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 5, 12:13=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> > You'll also find that changes (like switching the Nobl SRAM to DRAM as a=
n
> > example) can be accomodated without having to change *everything*.
>
> That has been on my mind because there is a DRAM on my board. Not only
> will the DRAM require more cycles but perhaps too a varying number of
> cycles depending on the sequentiality or randomness of the addressing.
>

Except for the most special case examples, DRAM access will be a
variable delay because of page changes and memory refresh.

Trying to design a state machine that is simply trying to *access*
memory for some algorithmic purpose would likely result in a difficult
to maintain design.

Designing a request/acknowledge interface to some other process or
entity (in this case the 'other' being a DRAM controller) results in a
much easier to maintain design.

Using the exact same interface signal functionality whether one is
talking to internal FPGA memory, NoBL or SDRAM or SPI results in a
design that can be reused, retargeted and improved upon if necessary.

Using the same signal naming functionality as an existing documented
specification (i.e. Avalon, Wishbone) allows others to (re)use your
design without getting bogged down in details that they are not
currently interested in and allows them (and you when you re-use the
design) to be more productive.

Figure out where you are and where you want to be in the design
productivity chain.  The synthesis cost in terms of logic resource is
zero, the upfront learning cost will start to pay back in the form of
quicker debug and reusable designs.

Kevin Jennings

Article: 131868
Subject: Re: Forking in One-Hot FSMs
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 05 May 2008 16:24:17 -0600
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> Kevin Neilson wrote:
>> Having two bits hot in a one-hot FSM would normally be a bad thing.
>> But I was wondering if anybody does this purposely, in order to fork,
>> which might be a syntactically nicer way to have a concurrent FSM.
> 
> DEC used that style of design in the PDP-16 Register Transfer Modules.
> Possibly also in the control units of some of their asynchronous
> processors such as the PDP-6 and KA10.

That's interesting--I'm not even familiar with an "asynchronous 
processor".  What does that mean?  -Kevin

Article: 131869
Subject: Re: Forking in One-Hot FSMs
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 05 May 2008 16:46:33 -0600
Links: << >>  << T >>  << A >>
KJ wrote:
> On May 5, 12:13 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> wrote:
>>> You'll also find that changes (like switching the Nobl SRAM to DRAM as an
>>> example) can be accomodated without having to change *everything*.
...
> Designing a request/acknowledge interface to some other process or
> entity (in this case the 'other' being a DRAM controller) results in a
> much easier to maintain design.
> 
> Using the exact same interface signal functionality whether one is
> talking to internal FPGA memory, NoBL or SDRAM or SPI results in a
> design that can be reused, retargeted and improved upon if necessary.
...
> Kevin Jennings

This is a great example, because switching from one type of RAM to 
another means you *do* have to change everything, if you want the 
controller to be good.  You can certainly modularlize the code and make 
concurrent SMs with handshaking and this is easy to maintain.  And a lot 
of DRAM controllers are designed this way.  But here is the problem: 
while you are waiting around for acknowledges, you have just wasted a 
bunch of memory bandwidth.  If you want to make better use of your 
bandwidth, you can't use handshaking.  You have to start another burst 
while one is in the pipe.  You have to look ahead in the command FIFO to 
see if the next request is going to be in the same row/bank to see if 
you need to close the row during this burst and precharge or if you can 
continue in the same open row in a different bank, etc.  If I do all 
that with handshaking, I'm frittering away cycles.  And to do this in a 
way that doesn't fritter away cycles with standard methodology means 
everything is so tightly bound together that to change from SDRAM to 
some other type of RAM means I have to tear up most of the design.

Another issue I came up with today in the design of my current SM is 
that I updated a value x and then in the next cycle realized I wanted 
the old value of x.  But I hadn't really updated x; I had issued a 
request that gets put into a matching delay line and then goes to a 
concurrent FSM which then updates x.  So even though I had "updated" x, 
I could still used the old value for a few cycles and didn't need a 
temporary storage register.  Again, I can't just send the request to 
update x and then wait for an ack because the SM has to keep on 
trucking.  This is confusing, and I'd like to have some sort of 
methodology that would be as efficient as what I'm doing but somewhat 
more abstract.
-Kevin

Article: 131870
Subject: Re: Style for Highly-Pipelined State Machines
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 05 May 2008 17:11:39 -0600
Links: << >>  << T >>  << A >>
KJ wrote:
> "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message 
> news:fvfm29$on81@cnn.xsj.xilinx.com...
>> KJ wrote:
>>> "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message 
>>> news:fv7i38$69n6@cnn.xsj.xilinx.com...
>>>> My question:  what is the cleanest way to describe an FSM requiring 
>>>> pipelining?
>> ...
>>> The other thing to consider is whether the latency being introduced by 
>>> this outsourced logic needs to be 'compensated for' in some fashion or is 
>>> it OK to simply wait for the acknowledge.  In some instances, it is fine 
>>> for the FSM to simply wait in a particular state until the acknowledge 
>>> comes back. In others you need to be feeding new data into the 
>>> hunk-o-logic on every clock cycle even though you haven't got the results 
>>> from the first back.  In that situation you still have the req/ack pair 
>>> but now the ack is simply saying that the request has been accepted for 
>>> processing, the actual results will be coming out later.  Now the 
>>> hunk-o-logic needs an additional output to flag when the output is 
>>> actually valid.  This output data valid signal would typically tend to 
>>> feed into a separate FSM or some other logic (i.e. 'usually' not the 
>>> first FSM).  The first FSM controls feeding stuff in, the second FSM or 
>>> other processing logic is in charge of taking up the outputs and doing 
>>> something with it.
>>>
>> ...
>>> Kevin Jennings
>> In this case I do indeed have to continue to keep the pipe full, so 
>> inserting wait states is not an option.  And the latency of the "hunk of 
>> logic", aka concurrent process, is actually significant because I have to 
>> get the result and feed it back into the FSM.  This example shows why:
>>
>> STATE2: begin
>>   if (condition)
>>     begin
>>       state <= STATE3;
>>       y     <= (a*b+c)*d;
>>     end
>> end
>>
>> I have to get the result (a*b+c) and then feed it back into the FSM so I 
>> can multiply by d.  Why not just let the concurrent process handle that? 
>> Because I want to limit my resource usage to a single DSP48, so I have to 
>> schedule the multiplications inside the FSM.  But I'll have to check out 
>> the Wishbone thing you're talking about.
> 
> Well, just the fact that you're time sharing the DSP48 means that you're not 
> processing something new on every clock cycle which just screams out to me 
> that you'd want to implement this with a request/acknowledge type of 
> framework.  ...
> 
> Kevin Jennings 
> 
> 
But I *do* have to process something on every cycle.  Consider that I 
have to process these two equations:

y0     <= (a0*b0+c0)*d0;
y1     <= (a1*b1+c1);

Now, if you look at the structure of the DSP48, you can see that I can't 
even process these two sequentially.  I can send off (a0*b0+c0)*d0 to 
the black box thingy you speak of, but this can't be processed without 
dead cycles:  I have to get the result of (a0*b0+c0) before I multiply 
it with d0, and if the DSP48 is fully pipelined, that means that the 
multiplier is unused for three cycles.  It's similar to a superscalar 
process with dependencies.  So I have to reschedule:  I put (a0*b0+c0) 
into the pipe, then put in (a1*b1+c1) (which has no dependency on what 
is in the pipe), and then when the result of (a0*b0+c0) pops out I can 
feed it back into the DSP48 and multiply it with d0 to get y0. In the 
meantime y1 pops out.  Without this intermixed scheduling I end up with 
too many dead cycles and then I need to use too many DSP48s.

Maybe what I really want is a way to take the superscalar scheduling 
techniques that have been used for a long time and apply them in a 
similar way to HDL.
-Kevin

Article: 131871
Subject: Re: Style for Highly-Pipelined State Machines
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 05 May 2008 17:30:59 -0600
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Kevin Neilson wrote:
> 
>> I have to get the result (a*b+c) and then feed it back into the FSM so I
>> can multiply by d.  Why not just let the concurrent process handle that?
>>  Because I want to limit my resource usage to a single DSP48, so I have
>> to schedule the multiplications inside the FSM.
> 
> I still like the idea of a step counter.
> 
> On tick one, I do x <= a * b *c;
> On tick two, I do y <= x * d;
> and so on ...
> 
>         -- Mike Treseler

That is essentially what I'm doing; I'm just trying to find a 
syntactically better way to design this pipelined stuff without having a 
bunch of interdependent concurrent FSMs (or a single FSM and a bunch of 
logic outside).  -Kevin

Article: 131872
Subject: Re: EDK9.2i simulation problems.
From: chrisdekoh@gmail.com
Date: Mon, 5 May 2008 17:10:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Goran,
   The FSL_Full Flag is not asserted. Also, the microblaze came out of
reset. I know cos I probed the addr and data bus signals and there is
information on the bus in the modelsim simulator, wrt to when the
microblaze is not out of reset.

    anyway, i found something else. This was what I wrote in my
firmware code running on microblaze:

#include "float.h"
#include "mb_interface.h"


typdef unsigned long long uint_64; //64 bits wide
typedef union {
  uint_64 long_t;
   double double_t;
} Union_double_t;



int  main(){
      Union_double_t a;
      Xuint32 temp;
     a= 3.0;

    //extract the lower word to put into the peripheral

     temp = (Xuint32) a.long_t  & 0xffffffff;
     microblaze_bwrite_fsl(temp,0);
    //extract the upper word to put into the peripheral
     temp = ((Xuint32) a.long_t >>32) | 0xffffffff;
     microblaze_bwrite_fsl(temp,0);
     return 1;
}

the code above does not work. In short, when i try to send a double
precision word onto the FSL bus like the manner described above by
breaking it into the lower word and the upper word, it fails to work.

However, for a single precision word sent in exactly the same way, it
works just fine.

any idea? :)
Chris


Article: 131873
Subject: Silicon
From: 854272335@qq.com
Date: Mon, 5 May 2008 18:07:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Silicon Wafers at PCASilicon.com
PCA supplies silicon wafers for the semiconductor industry. Our
products include wafers, thin films and more. We also offer polishing,
reclaiming, slicing and lapping of wafers.
http://www.ogogo123sina.cn/Silicon.htm

Article: 131874
Subject: Re: Argh! Need help debugging Xilinx .xsvf Player (XAPP058)
From: Bob <rsg.uClinux@gmail.com>
Date: Mon, 5 May 2008 19:54:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 5, 12:06 pm, "MM" <mb...@yahoo.com> wrote:

> I am not sure if this could be your problem, but... normally JTAG signals
> require pullups.

Oh?  I've never used them before, but then again, I've only used
iMPACT and the programming cable before...

This one I can't do until Wednesday, but I will try tacking on some
external pull-ups, if possible.  Frankly, I don't have a lot of hope
on this, but then again, nothing else seems to work either!

> Bitgen can (and probably does) enable them internally, but
> personally I've never relied upon them and always designed in external
> resistors...

Yes, Bitgen does enable them by default, and I didn't touch these...

> The behaviour with iMPACT might be different because there
> might be some pullups inside of the programming cable and/or simply the
> drivers/receivers are different.

Yeah, who knows?!

>
> /Mikhail

Thanks, but unless the pullups work Wednesday, I'm not sure I'm any
closer.  I certainly appreciate all your comments!  Any others?

-Bob




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search