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 142650

Article: 142650
Subject: Re: Yet Another Graphics Controller
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 24 Aug 2009 17:06:56 GMT
Links: << >>  << T >>  << A >>
"Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com> wrote:

>On Aug 23, 8:59=A0pm, Frank Buss <f...@frank-buss.de> wrote:
>> Antti.Luk...@googlemail.com wrote:
>> > did you check the genode-FX?
>>
>> > they have full gui and graphics library support also, all free to use
>>
>> Thanks, the high-level part is interesting. But I have browsed the VHDL
>> files and it seems that they don't implement any graphics acceleration,
>> except fast screen clear, and it is a standard framebuffer concept, but
>> still very complete with the software graphics library. Drawbacks are, th=
>at
>> it is available as GPL or commercial, only and very Xilinx specific. My
>> system is BSD, which might be better for small commercial projects and
>> should work on FPGAs from other vendors, too.
>>
>> --
>> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
>tems.de
>
>yes, GPL is real bad thing, one latest example is OpenOCD project
>they can not distribute compiled binaries if those support FTDI
>drivers
>due to GPL restrictions.

Fortunately you can also use the free USB drivers for the FTDI chips.
Not much is lost.

>recompiling OpenOCD from sources for windows is sure possible
>but having precompiled version would make live much more easier
>well, GPL prevents that...

Indeed. That pissed me off as well.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 142651
Subject: Re: Yet Another Graphics Controller
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Mon, 24 Aug 2009 10:19:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 24, 8:04=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> Frank Buss <f...@frank-buss.de> wrote:
> >Antti.Luk...@googlemail.com wrote:
>
> >> did you check the genode-FX?
>
> >> they have full gui and graphics library support also, all free to use
>
> >Thanks, the high-level part is interesting. But I have browsed the VHDL
> >files and it seems that they don't implement any graphics acceleration,
> >except fast screen clear, and it is a standard framebuffer concept, but
> >still very complete with the software graphics library. Drawbacks are, t=
hat
> >it is available as GPL or commercial, only and very Xilinx specific. My
> >system is BSD, which might be better for small commercial projects and
> >should work on FPGAs from other vendors, too.
>
> Did you even look into a Yamaha VG9938? This chip has acceleration for
> copying and line draw. AFAIK it is available as HDL source. There is
> also a VG9958 which is better & faster. These chips where used in MSX
> home computers.
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg=
er hammer!"
> --------------------------------------------------------------

MSX source is available (was) YES, so whatever is used there
should be there too

Antti



Article: 142652
Subject: Re: Yet Another Graphics Controller
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 24 Aug 2009 19:37:26 +0200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> Did you even look into a Yamaha VG9938? This chip has acceleration for
> copying and line draw. AFAIK it is available as HDL source. There is
> also a VG9958 which is better & faster. These chips where used in MSX
> home computers.

I've found some datasheet for V9938. Why do you think it is worth to take a
look at it? It looks like other graphics chips from this time, e.g. the MOS
6567 from the C64, but with some more features, like bitblitting and better
sprites.

Of course, my YaGraphCon has less features, but it is my first graphics
controller, so the main goal was that it works at least :-) Maybe I'll
enhance it with some microcode. Then it should be possible to implement
text mode or sprites with different microcode instead of hardwired hardware
and it would need less block RAM.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 142653
Subject: Re: Yet Another Graphics Controller
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Mon, 24 Aug 2009 10:59:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 24, 8:37=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> Nico Coesel wrote:
> > Did you even look into a Yamaha VG9938? This chip has acceleration for
> > copying and line draw. AFAIK it is available as HDL source. There is
> > also a VG9958 which is better & faster. These chips where used in MSX
> > home computers.
>
> I've found some datasheet for V9938. Why do you think it is worth to take=
 a
> look at it? It looks like other graphics chips from this time, e.g. the M=
OS
> 6567 from the C64, but with some more features, like bitblitting and bett=
er
> sprites.
>
> Of course, my YaGraphCon has less features, but it is my first graphics
> controller, so the main goal was that it works at least :-) Maybe I'll
> enhance it with some microcode. Then it should be possible to implement
> text mode or sprites with different microcode instead of hardwired hardwa=
re
> and it would need less block RAM.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
tems.de

cheer up!
great!

dont get upset on replies, most of us have not made a grpachical
controller
with hardware accelerated features in 3 days!

I havent.
MOST of the readers havent.
except YOU :)

the double RAM requirement is kinda nasty of course
its always too little of them, well Altera has more than X in low cost
families, hum, but i have no cyclone3s :(

Antti


Article: 142654
Subject: Re: Yet Another Graphics Controller
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 24 Aug 2009 20:31:55 +0200
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com wrote:

> cheer up!
> great!
> 
> dont get upset on replies, most of us have not made a grpachical
> controller
> with hardware accelerated features in 3 days!
> 
> I havent.
> MOST of the readers havent.
> except YOU :)

Thanks! I'm not getting upset. Maybe Nico has some good ideas he wants to
show me with the V9938. Do you have a link to VHDL source code for it?

> the double RAM requirement is kinda nasty of course
> its always too little of them, well Altera has more than X in low cost
> families, hum, but i have no cyclone3s :(

Yes, this is the main drawback. But this was the reason why it was so easy
to implement it: One exclusive read path for the graphics output, and one
read/write path for the accelerator, all clocked with the pixel clock. The
generic bit depth of the RAM is equal to the pixel depth. And I wrote
already the VGA output some years ago in Verilog (but I rewrote it for the
VHDL implementation, because the code was too messy). Bitblitting and line
drawing is trivial with such a simple structure.

I think when I'll add SRAM, which would need caching, bus arbitration etc.,
and maybe register configurable bit depth, it will be a lot more complex.
Maybe I can avoid some of the complexity with a microcode architecture, or
at least reduce the turnaround time for testing new code.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 142655
Subject: Re: Yet Another Graphics Controller
From: Torfinn Ingolfsen <tingo@start.no>
Date: Mon, 24 Aug 2009 20:51:33 +0200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> Did you even look into a Yamaha VG9938? This chip has acceleration for
> copying and line draw. AFAIK it is available as HDL source.

Interesting. Where is this available. A quick googling didn't find anyting.
-- 
Torfinn Ingolfsen,
Norway

Article: 142656
Subject: Re: Multiple Interrupt handling in XPS 8.2i
From: Jason Agron <jagron@gmail.com>
Date: Mon, 24 Aug 2009 12:26:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
You must make sure to acknowledge the interrupt source (your custom
core), and then the interrupt controller after each interrupt event
(as well as the CPU-specific interrupt handling).  Otherwise, the
active interrupt source will immediately trigger another interrupt as
soon as you exit your ISR.

-Jason

On Aug 20, 1:01=A0am, moon <moon3...@gmail.com> wrote:
> Iam using XPS 8.2i.I have built a custom peripheral and attached it
> to
> MicroBlaze (v 5.0) via OPB bus.My peripheral generates the two
> interrupts.These interrupts pins are input to the interrupt
> controller
> INTC (1.00 c).
> Initially both interrupts are disabled.Then only high priority
> interrupt is enabled.
> What my objective is that when a high priority interrupt occurs:in
> its
> ISR it should disabled itself and enabled the other interrupt on
> interrupt controller.
> But actually what is happening that when high priority interrupt is
> occurred it goes into its ISR and it doesnot disable itself.the other
> interrupt is enabled and the microblaze is stuck in handling both the
> interrupts.
> Any help in this regard is welcomed!


Article: 142657
Subject: Help with altera_attribute and AUTO_GLOBAL_CLOCK
From: James <jmos1277@gmail.com>
Date: Mon, 24 Aug 2009 13:17:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all, I've been working on a project using Quartus II (9.0 sp2) on a
Stratix II part.
This particular project requires that I set an attribute in the
Assignment editor to prevent the tools from automatically promoting
one of my signals to a global clock line. The entry in my QSF file
looks something like this:

set_instance_assignment -name AUTO_GLOBAL_CLOCK OFF -to
"myEntity:myEntity_inst|mySignal"

The great news is, the above statement works. The bad news is, I have
to move the attribute out of the QSF file and into my VHDL file to
make the file more portable. So, I read the manual to figure out how
to use the altera_attribute command, I put it into my VHDL code, and
the tool went right on ahead and ignored it. :-\ Below is a sample of
how I declared this particular attribute in my code. Does anyone have
any idea why the tool ignores my attribute when it's in my VHDL, but
doesn't when it's in my QSF file?

In case, you're wondering the signal that the tool wants to promote is
connected to the clock input of a register. I'm certain some will
recommend that I use this signal as an enable signal for the register.
However, I'm doing some non-traditional designs on the FPGA and this
is not an option. These designs work great as long as the attribute is
in the QSF file ... just not when it's in the VHDL file.

Thanks for any help you can provide,

James


EXAMPLE CODE:

architecture myArch of myEntity is

signal sig_a, sig_b : std_logic;
signal mySignal : std_logic;

attribute altera_attribute : string;
attribute altera_attribute of mySignal : signal is "-name
AUTO_GLOBAL_CLOCK OFF";

begin
...

-- The mySignal signal is connected to the clock input of a register
-- and the Altera tool REALLY wants to convert it to a global clock
--
mySignal <= sig_a xor sig_b;

...
end myArch;

Article: 142658
Subject: Why there is multi-source error in these VHDL code?
From: fl <rxjwg98@gmail.com>
Date: Mon, 24 Aug 2009 13:38:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
The following code is for address decode at different states. I
always
have the error message:



ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<1>>
Sources are:
   Signal <comp1/state/Out2> is assigned to logic
   Signal <RAM_out<1>> in Unit <vhdl_0> is assigned to GND

ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<0>>
Sources are:
   Signal <comp1/state/Out3> is assigned to logic
   Signal <RAM_out<0>> in Unit <vhdl_0> is assigned to GND

ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<2>>
Sources are:
   Signal <comp1/state/Out1> is assigned to logic
   Signal <RAM_in<2>> in Unit <vhdl_0> is assigned to GND

ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<1>>
Sources are:
   Signal <comp1/state/Out0> is assigned to logic
   Signal <RAM_in<1>> in Unit <vhdl_0> is assigned to GND

ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal
<RAM_in_sel<0>>
Sources are:
   Signal <comp1/state/Out4> in Unit <FSM_0> is assigned to GND
   Signal <RAM_in<0>> in Unit <vhdl_0> is assigned to GND

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





I cannot understand the reason. In fact, the code is just like a VHDL
textbook's. What's wrong with it? Thanks.




state_update: process(CLK, RESET)
begin
  if RESET = '1' then
    RAM_in_sel  <= (others => '0');
    RAM_out_sel <= (others => '0');
 else
   if CLK'event and CLK = '1' then
    RAM_in_sel  <= RAM_in;
    RAM_out_sel <= RAM_out;
    state <= next_state;
  end if;
 end if;
end process;

state_p: process(state)
begin
   case state is
     when init =>
        RAM_in   <= "000";
        RAM_out <= "001";
        next_state <= st0;
    when st0 =>
       RAM_in_selection  <= "010";
       RAM_out_selection <= "011";
       next_state <= st1;
   when st1 =>
      RAM_in_selection  <= "100";
      RAM_out_selection <= "101";
      next_state <= init;
  when others =>
      RAM_in_selection  <= "000";
      RAM_out_selection <= "001";
      next_state <= init;
  end case;
end process;

Article: 142659
Subject: Re: Yet Another Graphics Controller
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 24 Aug 2009 20:51:18 GMT
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> wrote:

>Nico Coesel wrote:
>
>> Did you even look into a Yamaha VG9938? This chip has acceleration for
>> copying and line draw. AFAIK it is available as HDL source. There is
>> also a VG9958 which is better & faster. These chips where used in MSX
>> home computers.
>
>I've found some datasheet for V9938. Why do you think it is worth to take a
>look at it? It looks like other graphics chips from this time, e.g. the MOS
>6567 from the C64, but with some more features, like bitblitting and better
>sprites.

I programmed quite a lot with it. Besides the line drawing it has a
lot of nifty features like video overlay (a friend of mine used an
MSX-2 computer to put subtitles on his semi-pro videos), masking (and,
or, not / xor) and so on. Ofcourse it is a design from 1985 but a
modern FPGA can easely run such a videoprocessor at much higher
resoltions.

This pages seems to link to the VG9938 vhdl sources (VDP Video Display
Processor).
http://www.ohnaka.jp/wiki/wiki.cgi?page=%BB%F7%C8%F3VDP
 
This seems to be the main project page:
http://www.hat.hi-ho.ne.jp/tujikawa/esepld/

These guys seem to have managed to put an entire MSX2 computer inside
an FPGA.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 142660
Subject: Re: Soft Processor IP core report
From: -jg <jim.granville@gmail.com>
Date: Mon, 24 Aug 2009 14:34:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 24, 6:10=A0pm, "Antti.Luk...@googlemail.com"
<antti.luk...@googlemail.com> wrote:
> hi Jim,
>
> humm.. what IP core have you spotted doing context switch?
> I suppose there are some, NIOS-I used windowed register file
> (what could already be considered as context switch), my own
> ABM Risc uses ram-register context switch for subroutines
> and interrupts/thread, sure there must be others.. can you recall
> some?

None that do everything I would.... ;)

A couple of month ago, there was mention of one here that sounded like
it would time-slice, but it is rare to see.

 IMO Asymmetric slice should fit well into a FPGA - you could allocate
a fast/small block ram for the crucial interrupt/core tasks, and allow
more elastic off-memory for the rest.
 This would allow nice Debug options, and also run-time-sanity-checks,
where the
time-slice would run a continual watchdog/self test function.

I did find an Asian 89C2051 clone, that claimed  time-shared core, but
that is
silicon, not a FPGA core.

IIRCX Sparc also allows a split register frame, so you pass params in
one half, and get a fresh 'other half' for local variables. That has
call depth limits, and needs considerable SW support, but should give
very compact and fast code.

> as of 18 bit, yes and no, for block RAM only, yes the 18 bits is very
> nice  for 16 bit datapath, but for a SoC with external memory bus, a 18 b=
it
> core is nono

You can get  SRAM in x18 x24 widths, but you are right, the HW has to
have used that, and mostly they do not.

-jg

Article: 142661
Subject: Re: Soft Processor IP core report
From: green <atgreen85@gmail.com>
Date: Mon, 24 Aug 2009 14:35:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 23, 8:32=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Aug 22, 4:58=A0pm, green <atgree...@gmail.com> wrote:
>
> > On Aug 16, 5:51=A0am, "Antti.Luk...@googlemail.com"
>
> > <antti.luk...@googlemail.com> wrote:
> > > YES, there is no need to point to the "usual suspects"
> > > unless there is a real feeling, i have missed something obvious.
>
> > I've been working on a new `Free Software' soft core, but backwards.
> > The gcc/binutils/gdb/simulator ports are already in the upstream FSF
> > repositories. =A0I also have a qemu port and uClinux has just started t=
o
> > boot on the simulator.
>
> Interesting - how fast is the simulator ?

There are actually two simulators.   The first is the one built into
GDB, and it's a very basic instruction interpreter written in C.  I
don't know how to characterize the speed other than to say that the
uClinux kernel boots up to a busybox prompt in just a few seconds.

The second simulator is a port of qemu, which uses JIT compiler
technology to translate moxie instructions into x86 instructions on
the fly, and it's a fair bit faster for most applications.

>
> > It's a 32-bit load/store architecture. =A0Most instructions are 16-bits=
,
> > but it also has 48-bit instructions for dealing with 32-bit immediate
> > values. =A0I think this is fair trade-off that should result in compact
> > code. =A0The ISA was designed specifically to be an excellent target fo=
r
> > GCC, although it still need tweaking (I've blogged all the details).
>
> Be interesting to see how this pathway fits on =A0FPGA.

I'll let you know once I get there!

AG


>
> In FPGA cores, you'll find things like 18 bit opcodes, as that is the
> width
> of block ram.
>
> More recent FPGA cores also target the dual-port memory blocks that
> most
> new FPGA's now include, but few I've seen also context switch that
> memory.
> - ie given that the memory-block is often larger than any core
> register set needs,
> switching within that for fast interrupts, or even hard time-slicing
> better uses HW
> that is 'almost free'
>
> -jg


Article: 142662
Subject: Re: Yet Another Graphics Controller
From: Robert Swindells <rjs@fdy2.demon.co.uk>
Date: 25 Aug 2009 00:01:56 +0100
Links: << >>  << T >>  << A >>

Nico Coesel wrote:
>Frank Buss <fb@frank-buss.de> wrote:
>>Nico Coesel wrote:
>>
>>> Did you even look into a Yamaha VG9938? This chip has acceleration for
>>> copying and line draw. AFAIK it is available as HDL source. There is
>>> also a VG9958 which is better & faster. These chips where used in MSX
>>> home computers.
>>
>>I've found some datasheet for V9938. Why do you think it is worth to take a
>>look at it? It looks like other graphics chips from this time, e.g. the MOS
>>6567 from the C64, but with some more features, like bitblitting and better
>>sprites.
>
>I programmed quite a lot with it. Besides the line drawing it has a
>lot of nifty features like video overlay (a friend of mine used an
>MSX-2 computer to put subtitles on his semi-pro videos), masking (and,
>or, not / xor) and so on. Ofcourse it is a design from 1985 but a
>modern FPGA can easely run such a videoprocessor at much higher
>resoltions.
>
>This pages seems to link to the VG9938 vhdl sources (VDP Video Display
>Processor).
>http://www.ohnaka.jp/wiki/wiki.cgi?page=%BB%F7%C8%F3VDP
> 
>This seems to be the main project page:
>http://www.hat.hi-ho.ne.jp/tujikawa/esepld/
>
>These guys seem to have managed to put an entire MSX2 computer inside
>an FPGA.

People have also recreated the Amiga <http://home.hetnet.nl/~weeren001/>
and Atari ST <http://www.experiment-s.de/de/atari-ste-in-a-chip/> in
FPGAs. 

An accelerator that sat on a shared bus like WishBone or PLB with a
dumb framebuffer could be useful too. The VGA/LCD controller is
usually in the "most popular" list on OpenCores, so some people must
be using it.

Robert Swindells


Article: 142663
Subject: Re: Yet Another Graphics Controller
From: Mark McDougall <markm@vl.com.au>
Date: Tue, 25 Aug 2009 11:20:06 +1000
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> These guys seem to have managed to put an entire MSX2 computer inside
> an FPGA.

This project saw a brief commercial release in Japan in 2006.
<http://en.wikipedia.org/wiki/1chipMSX>

The full source was released and has been updated/improved by dedicated
hobbyists, and even ported to other platforms such as the TerASIC DE1
(EP2C20). I managed to port it to proprietary Cyclone-II based (EP2C35)
hardware a few years ago as well.

FWIW the problem (IMHO) with the commercial release was that the design
just barely fit inside the EP1C12. That left very little room for
improvements and almost no chance of ever utilising the USB connectors
routed on the PCB.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 142664
Subject: Re: Yet Another Graphics Controller
From: Mark McDougall <markm@vl.com.au>
Date: Tue, 25 Aug 2009 11:22:28 +1000
Links: << >>  << T >>  << A >>
Robert Swindells wrote:

> People have also recreated the Amiga <http://home.hetnet.nl/~weeren001/>
> and Atari ST <http://www.experiment-s.de/de/atari-ste-in-a-chip/> in
> FPGAs. 

I think you'd be hard-pressed to find an 8/16-bit computer that _hasn't_
been recreated in an FPGA! :)

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 142665
Subject: Re: Why there is multi-source error in these VHDL code?
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Tue, 25 Aug 2009 11:13:44 +0200
Links: << >>  << T >>  << A >>
Hi!

Probably this is a bug in XST. I also had quite a lot of problems with
it when I had an entity with a signal called RAM in it.
Instantiating this entity only once in the whole design worked fine, but
using it several times made XST go crazy...
Try some different names for the signals (perhaps without RAM in it) to
see whether this could be the problem.

Matthias


fl schrieb:
> Hi,
> The following code is for address decode at different states. I
> always
> have the error message:
> 
> 
> 
> ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<1>>
> Sources are:
>    Signal <comp1/state/Out2> is assigned to logic
>    Signal <RAM_out<1>> in Unit <vhdl_0> is assigned to GND
> 
> ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<0>>
> Sources are:
>    Signal <comp1/state/Out3> is assigned to logic
>    Signal <RAM_out<0>> in Unit <vhdl_0> is assigned to GND
> 
> ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<2>>
> Sources are:
>    Signal <comp1/state/Out1> is assigned to logic
>    Signal <RAM_in<2>> in Unit <vhdl_0> is assigned to GND
> 
> ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<1>>
> Sources are:
>    Signal <comp1/state/Out0> is assigned to logic
>    Signal <RAM_in<1>> in Unit <vhdl_0> is assigned to GND
> 
> ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal
> <RAM_in_sel<0>>
> Sources are:
>    Signal <comp1/state/Out4> in Unit <FSM_0> is assigned to GND
>    Signal <RAM_in<0>> in Unit <vhdl_0> is assigned to GND
> 
> ----------------
> 
> 
> 
> 
> 
> I cannot understand the reason. In fact, the code is just like a VHDL
> textbook's. What's wrong with it? Thanks.
> 
> 
> 
> 
> state_update: process(CLK, RESET)
> begin
>   if RESET = '1' then
>     RAM_in_sel  <= (others => '0');
>     RAM_out_sel <= (others => '0');
>  else
>    if CLK'event and CLK = '1' then
>     RAM_in_sel  <= RAM_in;
>     RAM_out_sel <= RAM_out;
>     state <= next_state;
>   end if;
>  end if;
> end process;
> 
> state_p: process(state)
> begin
>    case state is
>      when init =>
>         RAM_in   <= "000";
>         RAM_out <= "001";
>         next_state <= st0;
>     when st0 =>
>        RAM_in_selection  <= "010";
>        RAM_out_selection <= "011";
>        next_state <= st1;
>    when st1 =>
>       RAM_in_selection  <= "100";
>       RAM_out_selection <= "101";
>       next_state <= init;
>   when others =>
>       RAM_in_selection  <= "000";
>       RAM_out_selection <= "001";
>       next_state <= init;
>   end case;
> end process;


Article: 142666
Subject: Xilinx at LLVM developers meeting
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Tue, 25 Aug 2009 12:09:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
I see there are a couple of Xilinx people at the LLVM meeting coming up:
http://llvm.org/devmtg/2009-10/

Is the interest just in a replacement/alternate toolchain for the embedded 
CPUs or is it something more interesting around retargetting intensive 
code to FPGAs?

Given the momentum building behind LLVM and the work from Livermore and 
Darmstadt the later seems likely. 

---

cds


Article: 142667
Subject: [help]error from my own hard macro by FPGA edit
From: "icefish711" <icefish711@163.com>
Date: Tue, 25 Aug 2009 07:17:13 -0500
Links: << >>  << T >>  << A >>
I am working on the EARP,xilinx using ISE9.1i02 and planahead9.2.7. I tried
to designed a hard marco in Virtex2p and follow the guide book of xilinx.
But i have problem in my hard marco when implement the PAR,the error is
below:

ERROR: Macro bm_base_prm is located incorrectly on a region boundary.
       The external portion of the slice macro appears inside the region
boundary.
       The following external nets connect to slice macro bm_base_prm but
illegally cross the region boundary.Nets crossing region boundaries must be
defined in the slice macro.
            Net "dip_base_prm[0]"
            Net "dip_base_prm[1]"
            Net "dip_base_prm[2]"
            Net "dip_base_prm[3]"
 Net dip_base_prm is the line between the dymatic moudle and hadr marco.
It is very strangely that when I used xilinx's marco, it worked. But my
hard marco is not work when all other's configuration is the same.
  
can anyone help out of this problem.Thanks.




Article: 142668
Subject: Timing properties of FPGA devices at sub-clock frequencies
From: "Pallavi" <pallavi_mp@rediffmail.com>
Date: Tue, 25 Aug 2009 07:17:21 -0500
Links: << >>  << T >>  << A >>
Hi,

I am doing this course in embedded systems in which I've to do a project
using FPGA devices. The project description says that by using diversified
propagation delays within the implemented designs it is possible to
generate frequencies that are much higher than the system clock frequency.
The objective of the project is to propose and implement techniques for
generating signals (either frequencies of individual pulses) which are
below the clock period threshold. At the system level, the project consists
in determining propagation delays using programming tools (ISE platform).
At the experimental level, the estimated timing characteristics are to be
verified for repeatability, stability and consistency. I'm completely new
to this field and am not aware of the terminologies. Can anyone please help
me with this. Thanks.



Article: 142669
Subject: Re: [help]error from my own hard macro by FPGA edit
From: Fabian Schuh <xeroc@nntp.xeroc.org>
Date: Tue, 25 Aug 2009 12:45:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
icefish711 <icefish711@163.com> schrieb:
> I am working on the EARP,xilinx using ISE9.1i02 and planahead9.2.7. I tried
> to designed a hard marco in Virtex2p and follow the guide book of xilinx.
> But i have problem in my hard marco when implement the PAR,the error is
> below:
>
> ERROR: Macro bm_base_prm is located incorrectly on a region boundary.
>        The external portion of the slice macro appears inside the region
> boundary.
>        The following external nets connect to slice macro bm_base_prm but
> illegally cross the region boundary.Nets crossing region boundaries must be
> defined in the slice macro.
>             Net "dip_base_prm[0]"
>             Net "dip_base_prm[1]"
>             Net "dip_base_prm[2]"
>             Net "dip_base_prm[3]"
>  Net dip_base_prm is the line between the dymatic moudle and hadr marco.
> It is very strangely that when I used xilinx's marco, it worked. But my
> hard marco is not work when all other's configuration is the same.
>   
> can anyone help out of this problem.Thanks.

Can you post the relevant UCF section for the REGIONS and the LOC of your
macros?

best regards
 -- Fabian Schuh

Article: 142670
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 25 Aug 2009 16:49:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
Pallavi <pallavi_mp@rediffmail.com> wrote:
 
< I am doing this course in embedded systems in which I've to do a project
< using FPGA devices. The project description says that by using diversified
< propagation delays within the implemented designs it is possible to
< generate frequencies that are much higher than the system clock frequency.

I don't quite understand that part.

< The objective of the project is to propose and implement techniques for
< generating signals (either frequencies of individual pulses) which are
< below the clock period threshold. 

That part I can understand.

< At the system level, the project consists
< in determining propagation delays using programming tools (ISE platform).
< At the experimental level, the estimated timing characteristics are to be
< verified for repeatability, stability and consistency. I'm completely new
< to this field and am not aware of the terminologies. Can anyone please help
< me with this. Thanks.

Completely now to electronics hardware, digital electronics, or
progrmmable logic.

If you don't have some understanding of digital electronics, that
is a very hard way to start.  

Also, it is much harder in an FPGA, where the routing is
determined by the computer, than in wires and gates on a PC board.

This reminds me of the stories of Cray using PC board traces
to delay signals such that they would arrive at the desired
time at the destination gate.  

Basically, if you take a signal, delay it by two different values,
then feed the two into an XOR gate, you will get a pulse with
a length depending on the difference in the delay.

-- glen
 

Article: 142671
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 25 Aug 2009 19:15:29 +0200
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:

> Basically, if you take a signal, delay it by two different values,
> then feed the two into an XOR gate, you will get a pulse with
> a length depending on the difference in the delay.

But if you are out of luck, ISE synthesizes it all into one lookup element.

This sounds like a strange project description. They have to learn things
which are considered bad design in real world projects? If the FPGA vendor
changes something in the chip process, which could be perfectly within the
specification, your pulse generator might not work any more and if you are
working for a company, you can explain your boss, why she has to dump all
the 10,000 nice and shiny new devices.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 142672
Subject: Re: Why there is multi-source error in these VHDL code?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 25 Aug 2009 18:36:35 +0100
Links: << >>  << T >>  << A >>
On Mon, 24 Aug 2009 13:38:18 -0700 (PDT), fl <rxjwg98@gmail.com> wrote:

>Hi,
>The following code is for address decode at different states. I
>always
>have the error message:
>
>
>
>ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<1>>
>Sources are:
>   Signal <comp1/state/Out2> is assigned to logic
>   Signal <RAM_out<1>> in Unit <vhdl_0> is assigned to GND

How well did it work in simulation?

Look at documentation for the simulator's "drivers" command; this may help you
identify the unwanted signal source.

- Brian

Article: 142673
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 25 Aug 2009 18:03:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> wrote:
< glen herrmannsfeldt wrote:
 
<> Basically, if you take a signal, delay it by two different values,
<> then feed the two into an XOR gate, you will get a pulse with
<> a length depending on the difference in the delay.
 
< But if you are out of luck, ISE synthesizes it all into one 
< lookup element.

Yes, it likely has to be hand coded with the low level tools.
(I remember them in the Xact days, I haven't looked recently.)
 
< This sounds like a strange project description. They have to 
< learn things which are considered bad design in real 
< world projects? 

I think it is to learn and understand exactly why they are bad.
Though as I said, in the past they were used in real designs.
Maybe not anymore.  (Seymour is dead.)

< If the FPGA vendor changes something in the chip process, 
< which could be perfectly within the specification, your pulse 
< generator might not work any more and if you are working for 
< a company, you can explain your boss, why she has to dump all
< the 10,000 nice and shiny new devices.

There were some interesting designs that Peter Alfke used to
come up with, but he knew which were and were not going to work.

Among others, he has a divide by 2.5 counter.  (I don't think
it uses these tricks, but is interesting anyway.)  They can
be used for clocking on rising and falling edge, though.

-- glen


Article: 142674
Subject: Re: Why there is multi-source error in these VHDL code?
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 25 Aug 2009 11:25:46 -0700
Links: << >>  << T >>  << A >>
It's not clear what you are doing.
Maybe post the entire code.
If RAM_in and RAM_out are inputs then
this assignment may cause a multi-source.
Perhaps you meant RAM_in_selection or
perhaps RAM_in_sel?

>   case state is
>     when init =>
>        RAM_in   <= "000";
>        RAM_out <= "001";
>        next_state <= st0;
>    when st0 =>
>       RAM_in_selection  <= "010";
>       RAM_out_selection <= "011";
>       next_state <= st1;

Brad Smallridge
AiVision.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