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 147075

Article: 147075
Subject: Re: I'd rather switch than fight!
From: Chris Higgs <chiggs.99@googlemail.com>
Date: Tue, 13 Apr 2010 01:16:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 12, 7:44=A0pm, Paul <pault...@googlemail.com> wrote:

> Are you using Python to test VHDL or Verilog HDL? Which simulator are
> you using? I know of MyHDL, but if I could use Python to test my VHDL
> that would be interesting :-), particularly if I can use it to build
> my FPGA design too. For the later I'm currently use Tcl.

To test VHDL. We simulate in Riviera-PRO using VHPI to interface to
the simulation (embedding the python interpreter into Riviera), but
something similar could be done for Modelsim. The entity under test is
directly instantiated (no testframe wrapper) and all inputs/outputs
are driven/read directly from python. You can navigate through the
hierarchy as though each entity/signal were an attribute of the root
unit under test object. Tests are written using the python yield
statement (similar to myHDL). A test yields an event which returns
control back to the simulator, resuming the python execution when the
event happens. A simple but pointless example (the "<=3D" operator is
overloaded for convenience):

def clock(clk, period):
    clk <=3D 0
    while True:
        yield EventTimer(period)
        clk <=3D not clk.val

def test(tb):
    clkthr =3D tb.thread(clock(tb.uut.clk, 3.2))
    yield tb.uut.pkt.valid.edge(1)                       # Wait for a
rising edge on output valid
    print "pkt =3D %08X" % (tb.uut.pkt.data.val)
    tb.kill(clkthr)

The nicest part is the intuitive ease with which layers of abstraction
can be combined. I tend to write a class to handle queuing and
receiving data for each bus which calls a callback when a transfer is
complete.

We use makefiles to drive the test/regression suite and synthesis
tools from the command line. Would there be any advantage to combining
or linking the two?

Article: 147076
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Tue, 13 Apr 2010 10:39:01 +0200
Links: << >>  << T >>  << A >>
On 12/04/2010 17:00, cfelton wrote:
> e.
>>
>> MyHDL, on the other hand, has been around for many years, and has a
>> reasonable-sized community.  It is definitely worth looking at if you
>> are not happy with Verilog or VHDL.
>>
>>
>
> I don't believe there is any risk in trying/using MyHDL for the following
> reasons.
>
>     1.  It is stable and has been used for many FPGA and an ASIC project.
>     2.  It is open-source.
>     3.  The output is Verilog/VHDL, you can go back to an old flow if
> desired.
>
> The 3rd might not seem reasonable to some because it is computer generated
> HDL but it is not computer generated HDL like most think.  It is simply a
> translation from one RTL language to another RTL language (MyHDL ->
> Verilog/VHDL).  The structure will be the same just some minor name
> adjustments.
>

Point 1 is, I think, more important.  The reason I think MyHDL is a 
valid choice is that the software itself is pretty stable, and more 
importantly the community and developers are stable.  Point 3 (as you 
expanded on it) is more for damage limitation rather than risk 
mitigation.  It means that if MyHDL should suddenly go away or for some 
other reason be unusable, then your generated output is still useful. 
But having been bitten by using a useful but half-finished tool 
(confluence) whose developer went away (again, I don't blame him at all, 
but thank him for what he gave out), I think it is important to consider 
the risks involved in choosing tools like this.

MyHDL is open source, but that is not in itself a guarantee that the 
tool, its development, and its community will continue.  It's a 
guarantee that it always /can/ continue (if you are willing to put in 
the necessary resources) - but not that it /will/ continue.

With a project like this, you have to consider what would happen if the 
main developer went away (hit by a bus, hired by the competition, or 
just gets bored with it).  I think in the case of MyHDL, the community 
is strong enough to continue - with confluence, it was not (confluence 
was also open source).

I haven't done much FPGA work for a while, but if and when I get back to 
it, I will be using MyHDL.  All I am saying here is that these are 
issues that you need to think about before choosing a tool - just like 
you do before choosing a hardware vendor.

Article: 147077
Subject: Re: How to find latches in Xilinx ISE 10.1
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 13 Apr 2010 05:03:46 -0500
Links: << >>  << T >>  << A >>
>RCIngham wrote:
>> Perhaps they are in the .NGC file relating to the MicroBlaze processor.
As
>> this is a reused item, why were they not spotted before? I'll try to
>> synthesize some of the blocks separately...
>
>I think that I have read somewhere (where ? from another thread on
>latch inference ?) that the Microblaze core uses a few latches.
>So this could be a valid theory.
>
>You could test it by replacing your MB core with a dumb one,
>and see if the latches are still there.
>

A separate synthesis of the MB core yields the 3 latches, as does a
synthesis of one of the other designs using the same MB. 

Probably explains why no useful warnings in the Synthesis Report.

"Onward & Upward"
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147078
Subject: Nios Memory Protection Unit
From: julio <jpajpa2@gmail.com>
Date: Tue, 13 Apr 2010 03:31:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
is anyone out there using the Memory Protection Unit option in the
Nios II processor from Altera?
I am trying to use it in a simple system with no OS and would like to
know if it has been used before by someone else to help to asses if
the problems I am having are on my own code or if I can blame the MPU
implementation.

Regards,

julio

Article: 147079
Subject: Re: How to find latches in Xilinx ISE 10.1
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Tue, 13 Apr 2010 11:42:21 +0100
Links: << >>  << T >>  << A >>
"RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> writes:

> Greetings,
>
> The synthesis report on my design tells me that I have caused 3 latches to
> be created: 1 LDC and 2 LDP. I didn't intend to create any...
>
> Rather frustratingly, the reports aren't telling me which signals are
> associated with these latches, so that I can fix my code! My colleagues
> can't remember what the trick is. Please can someone enlighten me?

If you haven't found them yet (or for anyone later on finding this
thread), you could try our (free) tool which will narrow things down to
which module the latches are in.

http://www.conekt.net/fpgaoptim.html

It's how I first noticed that Microblaze has a few latches in it :)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 147080
Subject: EDK BFM Simulation
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Tue, 13 Apr 2010 06:37:10 -0500
Links: << >>  << T >>  << A >>
Has anyone managed to get access to the BFM simulation package. For some
reason I keep getting denied. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147081
Subject: Re: I'd rather switch than fight!
From: "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
Date: Tue, 13 Apr 2010 07:45:15 -0500
Links: << >>  << T >>  << A >>

>To test VHDL. We simulate in Riviera-PRO using VHPI to interface to
>the simulation (embedding the python interpreter into Riviera), but
>something similar could be done for Modelsim. The entity under test is
>directly instantiated (no testframe wrapper) and all inputs/outputs
>are driven/read directly from python. You can navigate through the
>hierarchy as though each entity/signal were an attribute of the root
>unit under test object. Tests are written using the python yield
>statement (similar to myHDL). A test yields an event which returns
>control back to the simulator, resuming the python execution when the
>event happens. A simple but pointless example (the "<=3D" operator is
>overloaded for convenience):
>
>def clock(clk, period):
>    clk <=3D 0
>    while True:
>        yield EventTimer(period)
>        clk <=3D not clk.val
>
>def test(tb):
>    clkthr =3D tb.thread(clock(tb.uut.clk, 3.2))
>    yield tb.uut.pkt.valid.edge(1)                       # Wait for a
>rising edge on output valid
>    print "pkt =3D %08X" % (tb.uut.pkt.data.val)
>    tb.kill(clkthr)
>

I imagine what you posted works very well and accomplishes what you intend.
 I think for a new users adopting Python testbenches MyHDL would be a much
better choice.  I is documented, has a nice manual, there are examples
available, and a community to support questions.  The user doesn't need to
worry about HDL conversion if they do not want.  Here is a basic example of
a testbench in MyHDL.  

    @instance
    def stimulus():
        rbuf = [0]
        wbuf = [0]
        
        TracePrint('Start Testbench')
        test_data1 = [0xAA, 0x55, 0x0B, 0x0C, 0x0D]
       
        TracePrint('Write Wishbone LEDs')
        yield fx2Model.WriteAddress(0x0101, 1)
        yield fx2Model.WriteAddress(0x0103, 0xAA)
        
        TracePrint('Read Wishbone LEDs')
        yield fx2Model.ReadAddress(0x0103, rbuf)
        
        # Setup for RAMP Test input
        yield fx2Model.WriteAddress(0x0800, 0x01)

        TracePrint('  Check Ramp Data')
        rmpData = 0
        r1 = []; r2=[]
        for jj in range(100):
            yield fx2Model.WaitData(fx2Model.EP8, 512)
            yield delay(128 * fx2Model.IFCLK_TICK)
            
            for ii in range(512):
                rdata = fx2Model.Read(fx2Model.EP8)
                r1.append(rdata); r2.append(rmpData)
                if rdata != rmpData:
                    pass # Add some an assert or error exception
                rmpData = (rmpData + 1) % 256

        print " "    
        yield delay(20*fx2Model.IFCLK_TICK)

        TracePrint('  Disable Ramp')
        yield fx2Model.WriteAddress(0x0800, 0x00)


chris	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147082
Subject: Re: How to find latches in Xilinx ISE 10.1
From: whygee <yg@yg.yg>
Date: Tue, 13 Apr 2010 15:12:34 +0200
Links: << >>  << T >>  << A >>
RCIngham wrote:
> A separate synthesis of the MB core yields the 3 latches, as does a
> synthesis of one of the other designs using the same MB. 
> 
> Probably explains why no useful warnings in the Synthesis Report.

I'm happy that I have helped you !

yg
-- 
http://ygdes.com / http://yasep.org

Article: 147083
Subject: Re: I'd rather switch than fight!
From: Chris Higgs <chiggs.99@googlemail.com>
Date: Tue, 13 Apr 2010 06:15:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Apr, 13:45, "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
wrote:
> I imagine what you posted works very well and accomplishes what you inten=
d.
> =A0I think for a new users adopting Python testbenches MyHDL would be a m=
uch
> better choice. =A0I is documented, has a nice manual, there are examples
> available, and a community to support questions. =A0The user doesn't need=
 to
> worry about HDL conversion if they do not want. =A0Here is a basic exampl=
e of
> a testbench in MyHDL.
<snip>

Agreed, I think MyHDL has a lot of potential and there is significant
functionality overlap and similarities to the environment our company
uses. What I'm lamenting is the reluctance of 'hardware engineers" to
adopt advances made in the software field, in terms of regression and
unit testing frameworks. More people should be using MyHDL or
homegrown alternatives to provide rapid simulation verification and
object oriented abstraction models. As a community we are very slow
moving when compared to other related fields.

I believe MyHDL would do well to emphasise more strongly the pure
testbench environment functionality. Many engineers do not want the
VHDL/verilog generation features but could make good use of the
simulation parts of MyHDL. Expanding the cosimulation interface
options to support ModelSim FLI and VHPI would help move it forward.

Thanks,

Chris

Article: 147084
Subject: Re: Nios Memory Protection Unit
From: jacko <jackokring@gmail.com>
Date: Tue, 13 Apr 2010 06:24:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
No I haven't used it, but i can not comment on your problem, not
knowing your problem, as you have not expressed it. people do not have
to use something to understand it, in fact they may not have used it
because of similar reasons.

So what's the problem?

Cheers jacko

Article: 147085
Subject: Re: EDK BFM Simulation
From: d_s_klein <d_s_klein@yahoo.com>
Date: Tue, 13 Apr 2010 10:19:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 13, 4:37=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> Has anyone managed to get access to the BFM simulation package. For some
> reason I keep getting denied.
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

They moved:
<http://www.xilinx.com/support/answers/30440.htm>

RK

Article: 147086
Subject: Re: Microblaze Reset
From: d_s_klein <d_s_klein@yahoo.com>
Date: Tue, 13 Apr 2010 10:27:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 8:57=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> Is it possible to define an internal reset for a microblaze system. Ideal=
y
> I would like it to come from the DCM locked signal. Do I need to define i=
t
> in the XBD file or is that just for external ports?
>
> Thanks
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I believe the net you're looking for is called "OPB_Rst".

You can write the code to connect it to DCM locked.

The XBD file is for nets that leave the chip.

RK

Article: 147087
Subject: Re: I'd rather switch than fight!
From: Paul <pault.eg@googlemail.com>
Date: Tue, 13 Apr 2010 13:01:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Apr, 14:15, Chris Higgs <chiggs...@googlemail.com> wrote:

> Agreed, I think MyHDL has a lot of potential and there is significant
> functionality overlap and similarities to the environment our company
> uses. What I'm lamenting is the reluctance of 'hardware engineers" to
> adopt advances made in the software field, in terms of regression and
> unit testing frameworks. More people should be using MyHDL or
> homegrown alternatives to provide rapid simulation verification and
> object oriented abstraction models. As a community we are very slow
> moving when compared to other related fields.

It possibly isn't reluctance - there isn't too much in the way of
resources to show how to get started, to investigate alternative
approaches, is there? (with the exception of MyHDL).

> I believe MyHDL would do well to emphasise more strongly the pure
> testbench environment functionality. Many engineers do not want the
> VHDL/verilog generation features but could make good use of the
> simulation parts of MyHDL. Expanding the cosimulation interface
> options to support ModelSim FLI and VHPI would help move it forward.

Agreed. Although, what's the approximate cost of a sim with FLI/VHPI?
Possibly out of the reach for experimenting. (again, + for MyHDL)

It might be considered better to use just the one language for sim +
RTL because then you're using just the one language. Although
currently I use two languages, one scripting language for various
hardware test scripts + fpga build, and then VHDL for testbenches and
RTL. If I'm able to script testbenches, then I'm still using two
languages. With MyHDL for example, then possibly it's one more step to
*really* only using one language.

My experiences with the Xilinx sim hasn't been the best in terms of
support for behavioural VHDL when I've used it in the past. Hmmmm...
if Xilinx sim supported Python...

Although Tcl is the scripting language I use mostly of late. I have
been investigating the possible use of scripting test benches with
Tcl, and I _think_ it should be possible to do things like the
following in Tcl (not with 8.4 though!)

bench UartTx {} {
  test sub UartTx_test {} {
    run * c
    run * bc
    reset
    run {set data $DATA; set wr 1; wait @clk; set wr 0}
    assert [getSerial] {0 $DATA 1}
  }

  sub getSerial {} {
      set t 8681 ; # 115200 baud
      wait @clk {!$ready}
      waitFor {$t / 2}; set start $serialOut
      set data 0
      repeat $BITS {
          waitFor $t
          set data [expr {($data << 1) | $serialOut}]
      }
      waitFor $t; set stop $serialOut
      return [list $start $data $stop]
    }

  sub c {} {set clk 0; wait 25; set clk 0; wait 25}
  sub bc {} {set baudClk 1; wait @clk; set baudClk 0; wait 173 @clk}
  sub reset {} {set rst 1; waitFor 100; wait @clk; set rst 0}
}

Then run the testbench a couple of times, something like:

foreach BITS {7 8} DATA {0x5a 0xa5} {
  verify -config {BITS $BITS} -const {DATA $DATA} UartTx
}

Tcl is pretty malleable, includes incrTcl OO in 8.6, but has the $,
expr, [] and # weirdness. I have _some_ of the above working but not
all. What I really need is a sim with Tcl 8.6. Or maybe a sim with
VHPI? I'll have to see if I beg, borrow or steal one. (;-) about the
last one, or two!).

Whatever the scripting language, I think it's good to at least have
the option of a reasonably succinct and expressive option for
scripting test benches.

Article: 147088
Subject: Re: Virtex-5 FPGA PCIe card
From: Eric Chomko <pne.chomko@comcast.net>
Date: Tue, 13 Apr 2010 15:20:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 12, 10:06=A0pm, "john.orla...@gmail.com" <john.orla...@gmail.com>
wrote:
> On Apr 12, 12:47=A0pm, Eric Chomko <pne.cho...@comcast.net> wrote:> I am =
working with a Virtex-5 FPGA PCIe-based board and want to create
> > three interfaces (lanes?). =A0One that is a two way serial interface
> > running at 1 MHz. =A0Another running at 1 MHz but only input to the
> > board. =A0The last interface or lane will be 16 bit input only running
> > at 28 MHz. =A0
>
> <snip>
>
> From the sounds of your post, I think your best bet would be to first
> start be getting a better handle on PCIe and how it works in general.
> Spending a few days reading through Mindshare's PCIe System
> Architecture book will probably help explain the general topology of
> PCIe. =A0Once the fundamentals of PCIe are understood, it will make
> mapping these to an FPGA implementation much easier.
>
> Here is Amazon's link to the book:
>
> http://www.amazon.com/Express-System-Architecture-Mindshare-Inc/dp/03...
>
> The Mindshare books are a goldmine, IMHO.
>
> Good luck,
>
> John

Thanks for the advice I will take it!

Eric

Article: 147089
Subject: Read from the compact flash
From: "bluds" <vtescandell@n_o_s_p_a_m.gmail.com>
Date: Tue, 13 Apr 2010 17:42:44 -0500
Links: << >>  << T >>  << A >>
Hi,

I'm going to use the compact flash as a store unit. It wouldn't have any
filesystem format. I will copy raw binary data to it starting from the
first sector.

Then the objective is to read this data from the compact and then copy it
to the fpga memory in order to use it to feed my design.

Can somebody give me some references about how should i implement the
compact flash controller. I'm new with FPGA and i don't have too much
idea.

Thanks a lot 

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147090
Subject: Implementing bidirectional bus inside the FPGA
From: Manmohan <mmmmec@gmail.com>
Date: Tue, 13 Apr 2010 16:43:10 -0700 (PDT)
Links: << >>  << T >>  << A >>

Hi all,

I would like to implement a router mesh (3x3) with bidirectional links
within the FPGA . I am using a Virtex 4 board. Since there are  a lot
of bidirectional buses in my design, I would like to know if it is
possible to implement all the buses using tristate logic? when I
snthesised only one single bidirectional bus, it was mapped to the
IOBs and consumed around 15% of the 240 IOBs.

I would like to know if there is any other way to implement a
bidirectional bus that does not use the IOBs ?


Thanks and Regards

Manmohan

Article: 147091
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Manmohan <mmmmec@gmail.com>
Date: Tue, 13 Apr 2010 16:49:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 7:43=A0am, Manmohan <mmm...@gmail.com> wrote:
> Hi all,
>
> I would like to implement a router mesh (3x3) with bidirectional links
> within the FPGA . I am using a Virtex 4 board. Since there are =A0a lot
> of bidirectional buses in my design, I would like to know if it is
> possible to implement all the buses using tristate logic? when I
> snthesised only one single bidirectional bus, it was mapped to the
> IOBs and consumed around 15% of the 240 IOBs.
>
> I would like to know if there is any other way to implement a
> bidirectional bus that does not use the IOBs ?
>
> Thanks and Regards
>
> Manmohan




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

I would like to add that my buses do not have to interface externally
to the chip. (ie none of the bidirectional links will have to go out
of the FPGA ) everything remains inside. So is there any way to
implement the same. ???

Article: 147092
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Andy Peters <google@latke.net>
Date: Tue, 13 Apr 2010 16:50:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 13, 4:43=A0pm, Manmohan <mmm...@gmail.com> wrote:
> Hi all,
>
> I would like to implement a router mesh (3x3) with bidirectional links
> within the FPGA . I am using a Virtex 4 board. Since there are =A0a lot
> of bidirectional buses in my design, I would like to know if it is
> possible to implement all the buses using tristate logic? when I
> snthesised only one single bidirectional bus, it was mapped to the
> IOBs and consumed around 15% of the 240 IOBs.
>
> I would like to know if there is any other way to implement a
> bidirectional bus that does not use the IOBs ?

No, internal tristates have vanished from Brand X FPGAs after the
XC4000 series.

I don't miss them. I don't see how they can possibly have any
advantage over distinct "going this way" and "going that way" buses.

-a

Article: 147093
Subject: Re: Read from the compact flash
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 14 Apr 2010 00:42:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
bluds <vtescandell@n_o_s_p_a_m.gmail.com> wrote:
 
> I'm going to use the compact flash as a store unit. It wouldn't have any
> filesystem format. I will copy raw binary data to it starting from the
> first sector.
 
> Then the objective is to read this data from the compact and then copy it
> to the fpga memory in order to use it to feed my design.
 
> Can somebody give me some references about how should i implement the
> compact flash controller. I'm new with FPGA and i don't have too much
> idea.

One of the modes of CF looks exactly like an IDE disk driver.
A CF to IDE converter can be made with pretty much no logic.

I believe there is also a mode that looks like a RAM.

-- glen

Article: 147094
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Wed, 14 Apr 2010 09:45:41 +0200
Links: << >>  << T >>  << A >>
On 13/04/2010 15:15, Chris Higgs wrote:
> On 13 Apr, 13:45, "cfelton"<cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
> wrote:
>> I imagine what you posted works very well and accomplishes what you intend.
>>   I think for a new users adopting Python testbenches MyHDL would be a much
>> better choice.  I is documented, has a nice manual, there are examples
>> available, and a community to support questions.  The user doesn't need to
>> worry about HDL conversion if they do not want.  Here is a basic example of
>> a testbench in MyHDL.
> <snip>
>
> Agreed, I think MyHDL has a lot of potential and there is significant
> functionality overlap and similarities to the environment our company
> uses. What I'm lamenting is the reluctance of 'hardware engineers" to
> adopt advances made in the software field, in terms of regression and
> unit testing frameworks. More people should be using MyHDL or
> homegrown alternatives to provide rapid simulation verification and
> object oriented abstraction models. As a community we are very slow
> moving when compared to other related fields.
>
> I believe MyHDL would do well to emphasise more strongly the pure
> testbench environment functionality. Many engineers do not want the
> VHDL/verilog generation features but could make good use of the
> simulation parts of MyHDL. Expanding the cosimulation interface
> options to support ModelSim FLI and VHPI would help move it forward.
>

I disagree with that.

I haven't done much programmable logic design, and what I have done was 
a few years ago now, so I don't have anything like the experience of 
most people in this group (I work mainly with embedded software in C, 
and some PC software in Python).  However, I have made small systems 
with both VHDL and Verilog.

What I can say is that both Verilog and VHDL are very verbose, they both 
have a lot of features that are confusing and lead easily to wrong code 
or extra effort (for example, the difference between the different 
assignments in Verilog, or the different logic, bit, and numeric types 
in VHDL).  There also seems to be a very unclear boundary between 
synthesisable and non-synthesisable parts of the languages, and there 
can be inconsistencies between simulation and working synthesised behaviour.

When I used confluence, my results were far better.  It was simpler and 
clearer, and it handles the low-level Verilog or VHDL details 
automatically.  You can't accidentally end up with a latch or 
asynchronous logic in your state machines - in fact, it won't let you 
generate latches at all.  You don't have registers that are reset in 
simulation and preset in synthesis, because all the Verilog/VHDL 
registers are generated with explicit resets (or presets).  You don't 
have problems when mixing signed and unsigned values, because these are 
handled correctly.

I haven't used MyHDL for more than brief tests, but it appears to give a 
similar isolation from the messy low-level details of Verilog and VHDL, 
while (even more than confluence) it gives you higher level features. 
People often compare Verilog to "C", and VHDL to "Ada" - I think they 
both share a lot with assembly language.

I am also unconvinced of the value of Verilog or VHDL functional 
simulation (timing simulation is another matter, of course), if the code 
you have written is not in Verilog or VHDL in the first place.  If your 
code is written in MyHDL, and the MyHDL conversion to Verilog/VHDL is 
accurate, then you can do all your functional testing entirely within 
Python and MyHDL.  cosimulation is only relevant when you have parts 
that are not written in MyHDL (and cannot easily be modelled in MyHDL).

confluence "died" because the author was more interested in formal 
verification systems than synthesis (or testbenches).  While 
testbenching and integration with Verilog and VHDL simulators is 
important, I believe it is more important to have good tools that help 
you write correct code in the first place, rather than just to find the 
mistakes you've made.

As I say, I don't have the experience in programmable logic design of 
most people here.  That may mean my opinions here are pretty worthless - 
perhaps I'd be happy with Verilog and VHDL if I spend longer getting 
used to them.  But it may also mean that I can think about this without 
the bias of long established practice.

Article: 147095
Subject: Re: EDK BFM Simulation
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Wed, 14 Apr 2010 03:05:39 -0500
Links: << >>  << T >>  << A >>
OK thanks I will take a look at the zip file but UG254 seems quite old so
I'm not sure if this is the files I need.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147096
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Manmohan <mmmmec@gmail.com>
Date: Wed, 14 Apr 2010 01:24:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 7:50=A0am, Andy Peters <goo...@latke.net> wrote:
> On Apr 13, 4:43=A0pm, Manmohan <mmm...@gmail.com> wrote:
>
> > Hi all,
>
> > I would like to implement a router mesh (3x3) with bidirectional links
> > within the FPGA . I am using a Virtex 4 board. Since there are =A0a lot
> > of bidirectional buses in my design, I would like to know if it is
> > possible to implement all the buses using tristate logic? when I
> > snthesised only one single bidirectional bus, it was mapped to the
> > IOBs and consumed around 15% of the 240 IOBs.
>
> > I would like to know if there is any other way to implement a
> > bidirectional bus that does not use the IOBs ?
>
> No, internal tristates have vanished from Brand X FPGAs after the
> XC4000 series.
>
> I don't miss them. I don't see how they can possibly have any
> advantage over distinct "going this way" and "going that way" buses.
>
> -a

Hi Thank you for the reply... But actually I am planning to implement
a single set of 8 bit wide bus for both input and output direction....
So , I need to have a bidirectional bus .... Is there any other way
other than tristating to implement such a bus ?

Article: 147097
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Manmohan <mmmmec@gmail.com>
Date: Wed, 14 Apr 2010 01:45:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 7:50=A0am, Andy Peters <goo...@latke.net> wrote:
> On Apr 13, 4:43=A0pm, Manmohan <mmm...@gmail.com> wrote:
>
> > Hi all,
>
> > I would like to implement a router mesh (3x3) with bidirectional links
> > within the FPGA . I am using a Virtex 4 board. Since there are =A0a lot
> > of bidirectional buses in my design, I would like to know if it is
> > possible to implement all the buses using tristate logic? when I
> > snthesised only one single bidirectional bus, it was mapped to the
> > IOBs and consumed around 15% of the 240 IOBs.
>
> > I would like to know if there is any other way to implement a
> > bidirectional bus that does not use the IOBs ?
>
> No, internal tristates have vanished from Brand X FPGAs after the
> XC4000 series.
>
> I don't miss them. I don't see how they can possibly have any
> advantage over distinct "going this way" and "going that way" buses.
>
> -a



Hi Below is the code I used for implementing a bidirectional
transciever...
IENTITY bidir IS
    PORT(
        bidir   : INOUT STD_LOGIC_VECTOR (7 DOWNTO 0);
        oe, clk : IN STD_LOGIC;
        inp     : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
        outp    : OUT STD_LOGIC_VECTOR (7 DOWNTO 0));
END bidir;

ARCHITECTURE Behav OF bidir IS
SIGNAL  a  : STD_LOGIC_VECTOR (7 DOWNTO 0);  -- DFF that stores
                                             -- value from input.
SIGNAL  b  : STD_LOGIC_VECTOR (7 DOWNTO 0);  -- DFF that stores
BEGIN                                        -- feedback value.

	 bidir <=3Da when oe =3D '1' else  (others =3D> 'Z');
	 PROCESS(clk)
    BEGIN
	 	     IF clk =3D '1' AND clk'EVENT THEN  -- Creates the flipflops
              a <=3D inp;
              b <=3D bidir;
             outp <=3D b;
        END IF;
    END PROCESS;


I also instantiated the above component as shown below in a top level
module :


entity Top is
    Port ( inp1 : in  STD_LOGIC_VECTOR (7 downto 0);
           inp2 : in  STD_LOGIC_VECTOR (7 downto 0);
           out1 : out  STD_LOGIC_VECTOR (7 downto 0);
           out2 : out  STD_LOGIC_VECTOR (7 downto 0);
			  oe1,oe2,clk: in STD_LOGIC
			  );
end Top;
architecture Behavioral of Top is

component bidir is

					port (        bidir   : INOUT STD_LOGIC_VECTOR (7 DOWNTO 0);
											  oe, clk : IN STD_LOGIC;
												inp     : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
												outp    : OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
							);
end component;

 signal data : STD_LOGIC_VECTOR ( 7 downto 0);

begin


	t1 : bidir port map( inp =3D> inp1, outp =3D> out1, oe =3D> oe1, clk =3D>
clk, bidir =3D> data);
	t2 : bidir port map(inp =3D> inp2, outp =3D> out2, oe =3D> oe2, clk =3D> c=
lk,
bidir =3D> data);



end Behavioral;


I synthesized the entire design using Xilinx IST :  The synthesise
mapped the tristate logic to IOBs and this single design was taking
nearly 15 % of all available IOB.

Then I changed the options in Xilinx IST and unselected the Add IO
Buffers option in the synthesis options. When I did that... I got the
following synthesis  message :

WARNING:Xst:2042 - Unit bidir: 8 internal tristates are replaced by
logic (pull-up yes): bidir<0>, bidir<1>, bidir<2>, bidir<3>, bidir<4>,
bidir<5>, bidir<6>, bidir<7>.
INFO:Xst:2261 - The FF/Latch <t2/b_0> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_0>
INFO:Xst:2261 - The FF/Latch <t2/b_1> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_1>
INFO:Xst:2261 - The FF/Latch <t2/b_2> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_2>
INFO:Xst:2261 - The FF/Latch <t2/b_3> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_3>
INFO:Xst:2261 - The FF/Latch <t2/b_4> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_4>
INFO:Xst:2261 - The FF/Latch <t2/b_5> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_5>
INFO:Xst:2261 - The FF/Latch <t2/b_6> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_6>
INFO:Xst:2261 - The FF/Latch <t2/b_7> in Unit <Top> is equivalent to
the following FF/Latch, which will be removed : <t1/b_7>
INFO:Xst:2261 - The FF/Latch <t2/outp_0> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_0>
INFO:Xst:2261 - The FF/Latch <t2/outp_1> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_1>
INFO:Xst:2261 - The FF/Latch <t2/outp_2> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_2>
INFO:Xst:2261 - The FF/Latch <t2/outp_3> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_3>
INFO:Xst:2261 - The FF/Latch <t2/outp_4> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_4>
INFO:Xst:2261 - The FF/Latch <t2/outp_5> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_5>
INFO:Xst:2261 - The FF/Latch <t2/outp_6> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_6>
INFO:Xst:2261 - The FF/Latch <t2/outp_7> in Unit <Top> is equivalent
to the following FF/Latch, which will be removed : <t1/outp_7>


Could you please help me understand what is happening?



Article: 147098
Subject: Re: Implementing bidirectional bus inside the FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 14 Apr 2010 08:47:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Manmohan <mmmmec@gmail.com> wrote:
(snip)
 
> Hi Thank you for the reply... But actually I am planning to implement
> a single set of 8 bit wide bus for both input and output direction....
> So , I need to have a bidirectional bus .... Is there any other way
> other than tristating to implement such a bus ?

As far as I know, the synthesis tools will generate an emulated
tristate bus.  One can imagine a combination of AND/OR logic that,
as long as only one enable is active, generates the expected result.
In addition, it doesn't fail if other than one enable is active.

The problem is, that as chips get bigger it is necessary to
buffer the interconnect lines, which you can't do if you don't
know the direction.  Even if the signal has to go twice as far
(which it may have to do) it is still faster.

-- glen

Article: 147099
Subject: Re: Read from the compact flash
From: "bluds" <vtescandell@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Wed, 14 Apr 2010 03:59:08 -0500
Links: << >>  << T >>  << A >>
>bluds <vtescandell@n_o_s_p_a_m.gmail.com> wrote:
> 
>> I'm going to use the compact flash as a store unit. It wouldn't have
any
>> filesystem format. I will copy raw binary data to it starting from the
>> first sector.
> 
>> Then the objective is to read this data from the compact and then copy
it
>> to the fpga memory in order to use it to feed my design.
> 
>> Can somebody give me some references about how should i implement the
>> compact flash controller. I'm new with FPGA and i don't have too much
>> idea.
>
>One of the modes of CF looks exactly like an IDE disk driver.
>A CF to IDE converter can be made with pretty much no logic.
>
>I believe there is also a mode that looks like a RAM.
>
>-- glen
>

What do you refer when you talk about modes??

Do you know anywhere where i can find information about how to access the
compact, because i never used a FPGA and i don't know how to access a
remote device.

Thanks
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



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