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 154800

Article: 154800
Subject: Do you have any BROKEN Xilinx Platform Cable Usb or II
From: Enes Erdin <eneserdin@gmail.com>
Date: Sat, 12 Jan 2013 01:10:13 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I need this because of the stupid bureoacracy of my workplace. People in Turkey or USA are wanted.

Thanks in advance,

--enes

Article: 154801
Subject: Re: FPGA board with SD card slot (code test)
From: "nba83" <3224@embeddedrelated>
Date: Sun, 13 Jan 2013 00:07:59 -0600
Links: << >>  << T >>  << A >>
>Hello,
>
>I'm looking for some kind person who could test my SD card controller.
>Board with SD card slot with 4 data pins connected is needed.
>I'm asking for it because I've designed my own board and I can trust it
too
>much ;) So I'd like to check if I have now hardware or VHDL problem.
>
>Best regards,
>Pavel	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

hi,
I have a custom designed board with Xilinx xc95288 and a Micro SD memory
slot(4bits), I am working on this topic (both 1 bit and 4 bit), I have not
progressed in 4 bit so much so i 'm willing to test your hdl to learn more
if you don't mind.
Regards,
Neda Baheri
 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154802
Subject: Re: Quartus 12.1 Web Edition in 64-bit Linux - in System Sources and
From: wzab01@gmail.com
Date: Sun, 13 Jan 2013 05:53:39 -0800 (PST)
Links: << >>  << T >>  << A >>
In the 32-bit environment in Linux, the situation is even worse, as the attempt to use "In System Sources and Probes Editor" leads to segmentation fault:

*** Fatal Error: Segment Violation at 0x1c7
Module: quartus
Stack Trace:
    0x44148: BNLQ_DATA_TABLE_VIEW::update_table_column(unsigned int) + 0x208 (sld_bnlq)
    0x444fd: BNLQ_NODE_WIDGET::update_table_view(unsigned int) + 0x39 (sld_bnlq)
    0x4579b: BNLQ_DATA_WIDGET::update_node_view(unsigned int) + 0xbb (sld_bnlq)
    0x4588e: BNLQ_WIDGET::on_update(unsigned int) + 0xda (sld_bnlq)
    0x4769f: BNLQ_LAYOUT_WIDGET::update_all_widgets(QWidget*, unsigned int) + 0x41 (sld_bnlq)
    0x4e236: BNLQ_DATA_TABLE_VIEW::draw_timebar() + 0x104 (sld_bnlq)
    0x52252: BNLQ_DATA_TABLE_VIEW_HEADER::mouseMoveEvent(QMouseEvent*) + 0x22a (sld_bnlq)
   0x1aeb11: QWidget::event(QEvent*) + 0x611 (QtGui.so.4)
   0x5b70f3: QFrame::event(QEvent*) + 0x33 (QtGui.so.4)
   0x656392: QAbstractScrollArea::viewportEvent(QEvent*) + 0x32 (QtGui.so.4)
   0x710265: QAbstractItemView::viewportEvent(QEvent*) + 0x525 (QtGui.so.4)

   0x1798c1: QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) + 0x91 (QtCore.so.4)
   0x1489a3: QApplicationPrivate::notify_helper(QObject*, QEvent*) + 0x93 (QtGui.so.4)
   0x151104: QApplication::notify(QObject*, QEvent*) + 0x18f4 (QtGui.so.4)
   0x17947b: QCoreApplication::notifyInternal(QObject*, QEvent*) + 0x7b (QtCore.so.4)
   0x14b9a2: QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) + 0xf2 (QtGui.so.4)

   0x1dafe6: QApplication::x11ProcessEvent(_XEvent*) + 0x1966 (QtGui.so.4)

   0x17850d: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 0x4d (QtCore.so.4)
   0x17879a: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 0xaa (QtCore.so.4)
   0x17a811: QCoreApplication::exec() + 0xb1 (QtCore.so.4)
   0x148317: QApplication::exec() + 0x27 (QtGui.so.4)
     0x633f: __gxx_personality_v0 + 0x373 (quartus)
    0x23208: msg_main_thread(void*) + 0x18 (ccl_msg)
     0x5e5e: thr_final_wrapper + 0xe (ccl_thr)
    0x23f1b: msg_thread_wrapper(void* (*)(void*), void*) + 0x6c (ccl_msg)
    0x1591d: mem_thread_wrapper(void* (*)(void*), void*) + 0xdd (quartus)
     0xffd8: err_thread_wrapper(void* (*)(void*), void*) + 0x2a (ccl_err)
     0x62ba: thr_thread_wrapper + 0x2f (ccl_thr)
    0x367c7: msg_exe_main(int, char const**, int (*)(int, char const**)) + 0xb7 (ccl_msg)
     0x6411: __gxx_personality_v0 + 0x445 (quartus)
    0x16e46: __libc_start_main + 0xe6 (c.so.6)
     0x61f1: __gxx_personality_v0 + 0x225 (quartus)

End-trace

Quartus II 32-bit Version 12.1 Build 177 11/07/2012 SJ Web Edition

Article: 154803
Subject: Re: FPGA board with SD card slot (code test)
From: "pavel.m" <4030@embeddedrelated>
Date: Sun, 13 Jan 2013 15:30:33 -0600
Links: << >>  << T >>  << A >>
>>Hello,
>>
>>I'm looking for some kind person who could test my SD card controller.
>>Board with SD card slot with 4 data pins connected is needed.
>>I'm asking for it because I've designed my own board and I can trust it
>too
>>much ;) So I'd like to check if I have now hardware or VHDL problem.
>>
>>Best regards,
>>Pavel	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>
>
>hi,
>I have a custom designed board with Xilinx xc95288 and a Micro SD memory
>slot(4bits), I am working on this topic (both 1 bit and 4 bit), I have
not
>progressed in 4 bit so much so i 'm willing to test your hdl to learn
more
>if you don't mind.
>Regards,
>Neda Baheri
> 	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

Hi Neda,

I'm not sure if you got my message. If not, please write to me:
pavelmlasek(at)gmail.com	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154804
Subject: Re: Chisel as alternative HDL
From: Jecel <jecel@merlintec.com>
Date: Sun, 13 Jan 2013 14:58:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote:
> On 08/01/13 03:06, Martin Schoeberl wrote:=20
> > MyHDL
> > Chisel
> > Lava
> > Gezel
> > JHDL
> > Confluence
> > HDCamel
>=20
> Be careful that both Confluence and HDCamel are "dead" languages - the
> single developer has moved on.

I am not sure if this is also the case of IDaSS, which is written in Visual=
Works Smalltalk and can generate VHDL and Verilog:

http://averschu.home.xs4all.nl/idass/

I am planning to do something very similar. I don't like to have to write t=
ext for things I understand more easily visually, like schematics and state=
 machines. I know that graphical representations aren't very dense compared=
 to text, but that just means we need better zooming and scrolling.

-- Jecel

Article: 154805
Subject: is this multicycle?
From: "kaz" <3619@embeddedrelated>
Date: Mon, 14 Jan 2013 09:34:14 -0600
Links: << >>  << T >>  << A >>

Hi all,

A counter runs on system clock, counting from 0~95 in steps of 1.
every 3 counts, registers for two signals are updated (data signal and
write signal to ram).

I first assumed both data and write target registers are multicycle but now
have doubts since that implies that fitter may delay data signal
differently from write signal though each is multicycle leading to wrong
data being written into ram.

Any thoughts please?

Thanks 

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

Article: 154806
Subject: Re: Chisel as alternative HDL
From: jonesandy@comcast.net
Date: Mon, 14 Jan 2013 07:41:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, January 13, 2013 4:58:07 PM UTC-6, Jecel wrote:
> On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote: > On 08/=
01/13 03:06, Martin Schoeberl wrote: > > MyHDL > > Chisel > > Lava > > Geze=
l > > JHDL > > Confluence > > HDCamel > > Be careful that both Confluence a=
nd HDCamel are "dead" languages - the > single developer has moved on. I am=
 not sure if this is also the case of IDaSS, which is written in VisualWork=
s Smalltalk and can generate VHDL and Verilog: http://averschu.home.xs4all.=
nl/idass/ I am planning to do something very similar. I don't like to have =
to write text for things I understand more easily visually, like schematics=
 and state machines. I know that graphical representations aren't very dens=
e compared to text, but that just means we need better zooming and scrollin=
g. -- Jecel

I remember way too many years ago when I was faced with transitioning from =
schematic entry to HDL based design entry for FPGAs. I ignorantly quipped t=
o my boss; "Software is moving forward from writing code to drawing picture=
s, why are we hell-bent for leather, moving in the opposite direction?!" Ye=
ars later, he handed me a copy of a page from one of his notebooks on which=
 he had written it down, much to my chagrin.

The answer lies in the decades of developement of the all design, implement=
ation, analysis, review, test and revision management technology/practices =
that have been developed to support code-based design entry for SW (though =
SW considers coding as implementation, not design). We (HW) have been able =
to leverage these SW technology/practices to immense benefit with regards t=
o productivity, reliability and maintainability in FPGA and ASIC developmen=
t.=20

Back to the subject at hand: How do graphical design entry methods leverage=
 these same (or equivalently robust) technologies and practices? For instan=
ce, can a revision management system intelligently assist the user in mergi=
ng multiple changes to a module, if that module was entered (and is maintai=
ned) in graphical form? Can it intelligently (and thoroughly) compare two r=
evisions of the design to see what changed, ignoring cosmetic changes? Can =
it compare two modified revisions to their common ancester? These three exa=
mples apply to only one of the several activities/technologies employed in =
the development and mainenance of a product.

Andy

Article: 154807
Subject: Re: is this multicycle?
From: "kaz" <3619@embeddedrelated>
Date: Mon, 14 Jan 2013 09:47:06 -0600
Links: << >>  << T >>  << A >>
reposting sorry

Hi all,

A counter runs on system clock, counting from 0~95 in steps of 1.
every 3 counts, registers for two signals are updated (data signal andwrite

signal to ram).

I first assumed both data and write target registers are multicycle but now

 have doubts since that implies that fitter may delay data
signaldifferently 
 from write signal though each is multicycle leading to wrongdata being
written
 into ram.

Any thoughts please?

Thanks 

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

Article: 154808
Subject: Re: is this multicycle?
From: jonesandy@comcast.net
Date: Mon, 14 Jan 2013 07:59:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote:
> Hi all, A counter runs on system clock, counting from 0~95 in steps of 1.=
 every 3 counts, registers for two signals are updated (data signal and wri=
te signal to ram). I first assumed both data and write target registers are=
 multicycle but now have doubts since that implies that fitter may delay da=
ta signal differently from write signal though each is multicycle leading t=
o wrong data being written into ram. Any thoughts please? Thanks Kaz ------=
--------------------------------- Posted through http://www.FPGARelated.com

First, registers are not multi-cylce paths. Paths are multicycle.=20

We cannot tell from your description whether you intend the paths into the =
registers might be MC, or whether the path from the registers to the RAM mi=
ght be MC.=20

Depending on how the RAM is enabled, the path from the registers to the RAM=
 might be multi-cycle.=20

It is impossible to know about the paths into the registers. Do ALL the sig=
nals that drive ANY combinatorial logic that drives the registers (apart fr=
om the implied clock enable) also only change on the same clock edge, every=
 3rd clock?

Finally, multi-cycle (and false) path constraints are the most difficult to=
 verify that you specified them correctly, and did not unintentionally rela=
x the timing constraint on a specific path that is actually NOT MC/F. Verif=
ying this takes either very expensive analysis tools, or carefully construc=
ted, extensive simulations (with full timing) at the gate level. STA just a=
ssumes you specified the constraint correctly.=20

Andy

Article: 154809
Subject: Re: is this multicycle?
From: "kaz" <3619@embeddedrelated>
Date: Mon, 14 Jan 2013 10:19:09 -0600
Links: << >>  << T >>  << A >>
>On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote:
>> Hi all, A counter runs on system clock, counting from 0~95 in steps of
1.=
> every 3 counts, registers for two signals are updated (data signal and
wri=
>te signal to ram). I first assumed both data and write target registers
are=
> multicycle but now have doubts since that implies that fitter may delay
da=
>ta signal differently from write signal though each is multicycle leading
t=
>o wrong data being written into ram. Any thoughts please? Thanks Kaz
------=
>--------------------------------- Posted through
http://www.FPGARelated.com
>
>First, registers are not multi-cylce paths. Paths are multicycle.=20
>
>We cannot tell from your description whether you intend the paths into the
=
>registers might be MC, or whether the path from the registers to the RAM
mi=
>ght be MC.=20
>
>Depending on how the RAM is enabled, the path from the registers to the
RAM=
> might be multi-cycle.=20
>
>It is impossible to know about the paths into the registers. Do ALL the
sig=
>nals that drive ANY combinatorial logic that drives the registers (apart
fr=
>om the implied clock enable) also only change on the same clock edge,
every=
> 3rd clock?
>
>Finally, multi-cycle (and false) path constraints are the most difficult
to=
> verify that you specified them correctly, and did not unintentionally
rela=
>x the timing constraint on a specific path that is actually NOT MC/F.
Verif=
>ying this takes either very expensive analysis tools, or carefully
construc=
>ted, extensive simulations (with full timing) at the gate level. STA just
a=
>ssumes you specified the constraint correctly.=20

>
>Andy
>
Thanks Andy

The count value itself is used as enable(rather than using explicit
clkenable)
 My intention was that the path to above two registers is to be
multicycled
 and I didn't include the paths to ram (though they might be as well).
 There are no other comb signals entering the scene. 
 The data itself come from its registers that change every 3 clocks. The
 write is meant to be one clock pulse and is assigned from a wire set to
'1'
 always.

 My concern is that the write signal(one high pulse every three clocks)
may
 misalign with its data at ram leading to one extra wrong data or
duplicate.

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

Article: 154810
Subject: Re: is this multicycle?
From: jonesandy@comcast.net
Date: Mon, 14 Jan 2013 13:52:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, January 14, 2013 10:19:09 AM UTC-6, kaz wrote:
> >On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote: >> Hi all, A co=
unter runs on system clock, counting from 0~95 in steps of 1.=3D > every 3 =
counts, registers for two signals are updated (data signal and wri=3D >te s=
ignal to ram). I first assumed both data and write target registers are=3D =
> multicycle but now have doubts since that implies that fitter may delay d=
a=3D >ta signal differently from write signal though each is multicycle lea=
ding t=3D >o wrong data being written into ram. Any thoughts please? Thanks=
 Kaz ------=3D >--------------------------------- Posted through http://www=
.FPGARelated.com > >First, registers are not multi-cylce paths. Paths are m=
ulticycle.=3D20 > >We cannot tell from your description whether you intend =
the paths into the =3D >registers might be MC, or whether the path from the=
 registers to the RAM mi=3D >ght be MC.=3D20 > >Depending on how the RAM is=
 enabled, the path from the registers to the RAM=3D > might be multi-cycle.=
=3D20 > >It is impossible to know about the paths into the registers. Do AL=
L the sig=3D >nals that drive ANY combinatorial logic that drives the regis=
ters (apart fr=3D >om the implied clock enable) also only change on the sam=
e clock edge, every=3D > 3rd clock? > >Finally, multi-cycle (and false) pat=
h constraints are the most difficult to=3D > verify that you specified them=
 correctly, and did not unintentionally rela=3D >x the timing constraint on=
 a specific path that is actually NOT MC/F. Verif=3D >ying this takes eithe=
r very expensive analysis tools, or carefully construc=3D >ted, extensive s=
imulations (with full timing) at the gate level. STA just a=3D >ssumes you =
specified the constraint correctly.=3D20 > >Andy > Thanks Andy The count va=
lue itself is used as enable(rather than using explicit clkenable) My inten=
tion was that the path to above two registers is to be multicycled and I di=
dn't include the paths to ram (though they might be as well). There are no =
other comb signals entering the scene. The data itself come from its regist=
ers that change every 3 clocks. The write is meant to be one clock pulse an=
d is assigned from a wire set to '1' always. My concern is that the write s=
ignal(one high pulse every three clocks) may misalign with its data at ram =
leading to one extra wrong data or duplicate. Kaz -------------------------=
-------------- Posted through http://www.FPGARelated.com

OK, first, the functionality (whether clock cycles and data align properly =
is not affected/dictated by a multi-cycle path constraint. The constraint o=
nly relaxes the normal one-period STA-allowable propagation delay from any =
register to any other register on the same clock signal.=20

Whether the clock cycles and data align or not is a function of the RTL, an=
d should be observable in RTL simulation, and certainly in full-timing gate=
 level simulations. The gate level sims will also, if the correct condition=
s are simulated, show you whether the RTL plus the final timing and delays =
will still perform correctly.=20

From the sounds of it, if (and only if) the data to the registers is provid=
ed by registers that only update themselves on the SAME clock cycle. It is =
not enough to say that they both are enabled (only) every three clocks. The=
y must be enabled (only) at the same time every three clocks. Then you can =
probably put a multi-cyle path constraint of 3 clock cycles on the data pat=
h between the registers.

My rule of thumb is to NEVER add a multi-cycle path constraint unless the s=
ynthesis and/or P&R tool is having problems making the timing, and there ar=
e no other reasonable alternatives to resolve the problem (pipelining, etc)=
. The reason is, as I said earlier, these constraints are very hard to veri=
fy that they are accurately specified.=20

I used to go ahead and put multi-cycle path constraints in as soon as I was=
 aware of them (e.g. in RTL coding/simulation, before I even tried to synth=
esize or P&R), so that the P&R tool would not work so hard to meet timing I=
 did not need. Then I got bit a time or two with bad assumptions about the =
path and data (or changed the logic, and did not update the constraints!), =
and learned (the hard way) why that was not a good idea.=20

There could be times when not having a MCP constraint could cause the place=
r to distort the register placement such that other, single-cycle paths can=
not be routed and meet timing. I'll run off that bridge when I get there...=
 It hasn't happened yet.

Hope this helps,

Andy

Article: 154811
Subject: Re: Chisel as alternative HDL
From: Jecel <jecel@merlintec.com>
Date: Mon, 14 Jan 2013 21:25:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, January 14, 2013 1:41:02 PM UTC-2, Andy wrote:
> I remember way too many years ago when I was faced with transitioning fro=
m
> schematic entry to HDL based design entry for FPGAs. I ignorantly quipped
> to my boss; "Software is moving forward from writing code to drawing pict=
ures,
> why are we hell-bent for leather, moving in the opposite direction?!" Yea=
rs
> later, he handed me a copy of a page from one of his notebooks on which h=
e
> had written it down, much to my chagrin.

Schematics which could be unfolded on top of large desks were one thing, bu=
t schematics broken up into A4/letter sized pages with one block per page a=
nd labeled signals going to/from other pages are just very awkward netlists=
. So I see it as a two step process - we first made drawings really bad (ha=
ve you ever seen a good visual programming language?) and then we replaced =
the result with text.
=20
> The answer lies in the decades of developement of the all design,
> implementation, analysis, review, test and revision management
> technology/practices that have been developed to support code-based desig=
n
> entry for SW (though SW considers coding as implementation, not design). =
We
> (HW) have been able to leverage these SW technology/practices to immense
> benefit with regards to productivity, reliability and maintainability in =
FPGA
> and ASIC development.=20

As a Smalltalker, I have always considered these software tools an unfortun=
ate joke. But they are better than nothing and I have created my own system=
s (just because CVS, GIT and friends didn't exist when I did this) for the =
C side.

> Back to the subject at hand: How do graphical design entry methods levera=
ge
> these same (or equivalently robust) technologies and practices? For insta=
nce,
> can a revision management system intelligently assist the user in merging
> multiple changes to a module, if that module was entered (and is maintain=
ed)
> in graphical form? Can it intelligently (and thoroughly) compare two revi=
sions
> of the design to see what changed, ignoring cosmetic changes? Can it comp=
are
> two modified revisions to their common ancester? These three examples app=
ly to
> only one of the several activities/technologies employed in the developme=
nt
> and mainenance of a product.

I don't think diff does such a good job of ignoring cosmetic differences in=
 two text files. But you are correct that graphics add a level of complicat=
ions. Changing a pin in a library component which has both a schematic symb=
ol and a PCB layout, for example, is something a lot of tools don't get qui=
te right.

So I think you can get further with a bad text implementation than with a b=
ad graphical tool, but if done well then the graphical one will be more usa=
ble.

-- Jecel

Article: 154812
Subject: Combination loops and false paths
From: Rob Doyle <radioengr@gmail.com>
Date: Mon, 14 Jan 2013 22:54:53 -0700
Links: << >>  << T >>  << A >>

I creating an FPGA implementation of a old DEC PDP-10 (KS-10,
specifically) Mainframe Computer.  Why?  Because I always wanted one...

The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU.
At this stage, most of the instruction set diagnostics simulate correctly.

When I synthesize this design using Xilinx ISE I get warnings about
combinatorial loops involving the ALU - and an associated "Minimum
period: 656.595ns (Maximum Frequency: 1.523MHz)" message...

My understanding is that if combination loops really existed then the
simulation wouldn't stabilize. I can't really add pipelining or
registers to the design without affecting the microcode - and I don't
want to do that.

Most of the information that I've read about "false paths" assume two
clocked processes not a combinatorial loop.

Anyway.  I'm not sure how to resolve this.   I can mark the path as a
false path but I think that it will ignore /all/ the timing (even the
desired timing) through that path.

What should I do?

Rob.

Article: 154813
Subject: need help in writing VHDL code for modified booths algorithm using
From: Devesh Kishore <kishore.devesh@gmail.com>
Date: Mon, 14 Jan 2013 22:08:37 -0800 (PST)
Links: << >>  << T >>  << A >>
hi i want to write a vhdl code for booth modified radix4 algorithm using wallace tree(3:2) and need help in this.. please help

Article: 154814
Subject: Re: is this multicycle?
From: "kaz" <3619@embeddedrelated>
Date: Tue, 15 Jan 2013 06:52:23 -0600
Links: << >>  << T >>  << A >>

Thanks Andy, it all makes sense.

I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle
of 
input register itself) to improve timing which we are struggling with. The
design was showing malfunction pointing to that multicycle area.
I removed the multicycle (only this change made to build) and it is now 
outputting correct expected spectrum.

So I have to assume it was wrong multicycle but my own paper analysis
indicated 
it could be multicycle.

I believe the issue of multicycle must be automated by tools as part of
timing
analysis as it is indeed very hard to get right in many cases. 

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

Article: 154815
Subject: Re: is this multicycle?
From: jonesandy@comcast.net
Date: Tue, 15 Jan 2013 07:37:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, January 15, 2013 6:52:23 AM UTC-6, kaz wrote:
> Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 f=
or reasons to do with clock cycle of input register itself) to improve timi=
ng which we are struggling with. The design was showing malfunction pointin=
g to that multicycle area. I removed the multicycle (only this change made =
to build) and it is now outputting correct expected spectrum. So I have to =
assume it was wrong multicycle but my own paper analysis indicated it could=
 be multicycle. I believe the issue of multicycle must be automated by tool=
s as part of timing analysis as it is indeed very hard to get right in many=
 cases. Kaz --------------------------------------- Posted through http://w=
ww.FPGARelated.com

I believe you have hit upon the main reason I avoid MCP constraints. It is =
too easy to overly broadly specify the paths that are covered by an MCP, wh=
ich lead to issues that may be difficult to identify and debug. You were lu=
cky that the effects showed up quickly.=20

STA is strictly a structural analysis of the results of placing and routing=
 the FPGA. It does not include any knowledge about the functionality of the=
 logic, other than what is a combinatorial primitive, and what is a sequent=
ial primitive. Therefore, adding identification or verification of MCP cons=
traints to this process would be very difficult (the necessary information =
is not available in this process).

There are SW tools that perform analysis or even generation of multi-cycle =
and false path constraints from the RTL. Blue Pearl Software has one such t=
ool. I do not know much at all about it. If such capability were to be inte=
grated into the tool suite, it would likely be into the synthesis process, =
not the timing analysis process.=20

Andy

Article: 154816
Subject: Data output constraint
From: "pavel.m" <4030@embeddedrelated>
Date: Tue, 15 Jan 2013 13:57:47 -0600
Links: << >>  << T >>  << A >>
Hello,

I asked some time ago for constraints learning materials. It is hard to
learn only with reading, I think I should try it.

Here comes the time when I think only that can help me. I have problem with
sending data to SD memory. Data output and checksum values seem to be fine,
but SD says that there is checksum error. It works with 50MHz. I suppose
that there might be some delay between clock and data, maybe you could
suggest something else?
Could you help me with applying constraints to let the tools know that they
should be more careful with that sensitive data output part of design?

The only constraint, besides LOC for pinout, which I use is:
NET "clock" TNM_NET = "tnm_clock";
TIMESPEC "TS_clock" = PERIOD "tnm_clock" 20 ns HIGH 50 %;

But to be honest I don't see much difference with or without it. I just
read that it is one of basic and "must be" constraint.

Best regards,
Pavel
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154817
Subject: Re: is this multicycle?
From: GaborSzakacs <gabor@szakacs.invalid>
Date: Tue, 15 Jan 2013 15:33:43 -0500
Links: << >>  << T >>  << A >>
jonesandy@comcast.net wrote:
> On Tuesday, January 15, 2013 6:52:23 AM UTC-6, kaz wrote:
>> Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle of input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tools as part of timing analysis as it is indeed very hard to get right in many cases. Kaz --------------------------------------- Posted through http://www.FPGARelated.com
> 
> I believe you have hit upon the main reason I avoid MCP constraints. It is too easy to overly broadly specify the paths that are covered by an MCP, which lead to issues that may be difficult to identify and debug. You were lucky that the effects showed up quickly. 
> 
> STA is strictly a structural analysis of the results of placing and routing the FPGA. It does not include any knowledge about the functionality of the logic, other than what is a combinatorial primitive, and what is a sequential primitive. Therefore, adding identification or verification of MCP constraints to this process would be very difficult (the necessary information is not available in this process).
> 
> There are SW tools that perform analysis or even generation of multi-cycle and false path constraints from the RTL. Blue Pearl Software has one such tool. I do not know much at all about it. If such capability were to be integrated into the tool suite, it would likely be into the synthesis process, not the timing analysis process. 
> 
> Andy

Tools that automatically create multicycle constraints are not
inexpensive!

I generally only use milticycle constraints on registers that
are clearly coded to use a periodic clock enable.  Even then,
using the clock enable itself as a selector for the timing
group can bite you if you have also used the clock enable as
a feedback to itself like:

   if rising_edge(clock) then
      clock_enable <= not clock_enable;
   end if;

If you then use TNM_NET with clock_enable, you'll find that the
clock enable itself is included in this timing group.  Obviously
the clock enable should not be considered as a multicycle path.
So you need to be careful how you define your clock enable if
you're using it to determine multicycle paths.

You can of course use the actual net names to define the timing
groups for multicycle paths, but then you can often get into
trouble by using wildcards that match nets you didn't expect.

-- Gabor

Article: 154818
Subject: Re: Combination loops and false paths
From: GaborSzakacs <gabor@szakacs.invalid>
Date: Tue, 15 Jan 2013 15:40:24 -0500
Links: << >>  << T >>  << A >>
Rob Doyle wrote:
> 
> I creating an FPGA implementation of a old DEC PDP-10 (KS-10,
> specifically) Mainframe Computer.  Why?  Because I always wanted one...
> 
> The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU.
> At this stage, most of the instruction set diagnostics simulate correctly.
> 
> When I synthesize this design using Xilinx ISE I get warnings about
> combinatorial loops involving the ALU - and an associated "Minimum
> period: 656.595ns (Maximum Frequency: 1.523MHz)" message...
> 
> My understanding is that if combination loops really existed then the
> simulation wouldn't stabilize. I can't really add pipelining or
> registers to the design without affecting the microcode - and I don't
> want to do that.
> 

Combinatorial loops _with delay_ will simulate correctly.  Otherwise
you couldn't simulate a ring oscillator.

> Most of the information that I've read about "false paths" assume two
> clocked processes not a combinatorial loop.
> 
> Anyway.  I'm not sure how to resolve this.   I can mark the path as a
> false path but I think that it will ignore /all/ the timing (even the
> desired timing) through that path.
> 

Not necessarily true.  False paths have a FROM and a TO specification,
and would not affect other paths that don't start at the FROM or
don't end at the TO timing group.  This allows you for example to
say that you don't care how long a control register bit takes to
get through some logic, but you want the streaming data to get through
in the standard PERIOD time.

> What should I do?

You could always run your machine at 1.5 MHz.  After all, how fast
was the PDP-10?  Other than that, we'd probably need to analyze
this path to give any useful advice.

> 
> Rob.

Article: 154819
Subject: Re: Data output constraint
From: GaborSzakacs <gabor@szakacs.invalid>
Date: Tue, 15 Jan 2013 15:56:31 -0500
Links: << >>  << T >>  << A >>
pavel.m wrote:
> Hello,
> 
> I asked some time ago for constraints learning materials. It is hard to
> learn only with reading, I think I should try it.
> 
> Here comes the time when I think only that can help me. I have problem with
> sending data to SD memory. Data output and checksum values seem to be fine,
> but SD says that there is checksum error. It works with 50MHz. I suppose
> that there might be some delay between clock and data, maybe you could
> suggest something else?
> Could you help me with applying constraints to let the tools know that they
> should be more careful with that sensitive data output part of design?
> 
> The only constraint, besides LOC for pinout, which I use is:
> NET "clock" TNM_NET = "tnm_clock";
> TIMESPEC "TS_clock" = PERIOD "tnm_clock" 20 ns HIGH 50 %;
> 
> But to be honest I don't see much difference with or without it. I just
> read that it is one of basic and "must be" constraint.
> 
> Best regards,
> Pavel
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

The PERIOD constraint is a good starting point, but it only covers
internal paths from one flip-flop or other register (BRAM, DSP48...)
to another inside the FPGA.

Checksum errors could very likely indicate an issue with the interface
timing, which includes clock to output of the FPGA, and setup/hold
time at FPGA inputs.

You need to check the specs on your external device to calculate the
allowable setup and hold time at the FPGA.  Then you need to add an
OFFSET IN BEFORE constraint to ensure that these conditions are met
by the design.  For example if you determine that you have 3 ns setup
and 2 ns hold time with respect to the rising edge of the "clock" net:

OFFSET = IN 3 ns VALID 5 ns BEFORE "clock" RISING ;

This says that the valid data window starts 3 ns before the rising
edge of the clock input pin, and stays valid for 5 ns - that is until
2 ns after the rising edge of clock.

You can also constrain the clock to output timing like:

OFFSET = OUT 5 ns AFTER "clock" RISING;

This sets a maximum delay from the clock input pin to an output pad.
Note that there is no way to constrain a minimum delay, so if you
are using source-synchronous logic, you need to be sure that output
timing is met by design.  Normally this means placing output flops
in the IOB and using a DDR output register for the clock running
on a different phase from the data to allow hold time if necessary.

-- Gabor

Article: 154820
Subject: Re: Chisel as alternative HDL
From: Andy <jonesandy@comcast.net>
Date: Tue, 15 Jan 2013 14:30:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 14, 11:25=A0pm, Jecel <je...@merlintec.com> wrote:
> On Monday, January 14, 2013 1:41:02 PM UTC-2, Andy wrote:
> > The answer lies in the decades of developement of the all design,
> > implementation, analysis, review, test and revision management
> > technology/practices that have been developed to support code-based des=
ign
> > entry for SW (though SW considers coding as implementation, not design)=
. We
> > (HW) have been able to leverage these SW technology/practices to immens=
e
> > benefit with regards to productivity, reliability and maintainability i=
n FPGA
> > and ASIC development.
>
> As a Smalltalker, I have always considered these software tools an unfort=
unate joke. But they are better than nothing and I have created my own syst=
ems (just because CVS, GIT and friends didn't exist when I did this) for th=
e C side.
>
> > Back to the subject at hand: How do graphical design entry methods leve=
rage
> > these same (or equivalently robust) technologies and practices? For ins=
tance,
> > can a revision management system intelligently assist the user in mergi=
ng
> > multiple changes to a module, if that module was entered (and is mainta=
ined)
> > in graphical form? Can it intelligently (and thoroughly) compare two re=
visions
> > of the design to see what changed, ignoring cosmetic changes? Can it co=
mpare
> > two modified revisions to their common ancester? These three examples a=
pply to
> > only one of the several activities/technologies employed in the develop=
ment
> > and mainenance of a product.
>
> I don't think diff does such a good job of ignoring cosmetic differences =
in two text files. But you are correct that graphics add a level of complic=
ations. Changing a pin in a library component which has both a schematic sy=
mbol and a PCB layout, for example, is something a lot of tools don't get q=
uite right.

Diff (in CVS) does a horrible job! Try something capable like
BeyondCompare. Even the comparison capapilities in TortoiseSVN are
better than CVS/diff (I have not tried tortoiseCVS, it may be very
similar to tortoiseSVN).

>
> So I think you can get further with a bad text implementation than with a=
 bad graphical tool, but if done well then the graphical one will be more u=
sable.
>
> -- Jecel

Generally, if you work on a lot of small, one-man, one-off projects,
these capabilities may not interest you or make you more productive.
But when you work on large projects with several developers and a long
product life-cycles, these capabilities rise to the top.

Also, I think the relative preference of graphical/textual design
entry has a lot to do with your design style. If you tend to be a very
structural, concrete HW designer (e.g. if you think in terms of
circuit elements that will do what you want), the schematic paradigm
probably works great.

If on the other hand, you prefer designing at higher levels of
abstraction, and focus on the intended behavior of the design, along
with throughput and latency, then a textual paradigm works better.
Sure, there is still plenty of structure in even an abstract,
behavioral (yet synthesizeable) design of any size/complexity, but
abstracting interfaces using custom, aggregate data types (records,
arrays, arrays of arrays, arrays of records, etc.) reduces the
tediousness of the coding, and improves readability and
maintainability.

Andy

Article: 154821
Subject: Re: is this multicycle?
From: Andy <jonesandy@comcast.net>
Date: Tue, 15 Jan 2013 14:50:57 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 15, 2:33=A0pm, GaborSzakacs <ga...@szakacs.invalid> wrote:
>
> Tools that automatically create multicycle constraints are not
> inexpensive!
>
> I generally only use milticycle constraints on registers that
> are clearly coded to use a periodic clock enable. =A0Even then,
> using the clock enable itself as a selector for the timing
> group can bite you if you have also used the clock enable as
> a feedback to itself like:
>
> =A0 =A0if rising_edge(clock) then
> =A0 =A0 =A0 clock_enable <=3D not clock_enable;
> =A0 =A0end if;
>
> If you then use TNM_NET with clock_enable, you'll find that the
> clock enable itself is included in this timing group. =A0Obviously
> the clock enable should not be considered as a multicycle path.
> So you need to be careful how you define your clock enable if
> you're using it to determine multicycle paths.
>
> You can of course use the actual net names to define the timing
> groups for multicycle paths, but then you can often get into
> trouble by using wildcards that match nets you didn't expect.
>
> -- Gabor

Agreed on the cost of those tools... Tools like that have to be
leveraged across larger design teams.

Clock enable signals are almost NEVER multicycle themselves,
regardless of how they were generated (feedback or not). They still
have to propagate (on and off) from their source register to every
enabled register in only one clock.

And wildcards are just begging to include paths you did not intend to
include. When done accurately, they work great. The problem is
verifying they were done accurately. And just because a path is multi-
cycle constrained, does not mean it WILL take multiple clocks to
propagate in the final P&R results, making it impossible to know
whether it could have been multi-cycle and still worked. You'll never
know until some design/tool change suddenly lengthens the propagation
to longer than one clock, and boom!

It is relatively easy to add assert statements in the RTL such that
you can detect if the signal ever changes more recently than your
assumed MCP constraint, even in RTL simulation. The problem is making
sure the constrained paths are the same ones checked by the the
assertion!

Andy

Article: 154822
Subject: Re: is this multicycle?
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Jan 2013 21:10:06 -0500
Links: << >>  << T >>  << A >>
On 1/15/2013 7:52 AM, kaz wrote:
> Thanks Andy, it all makes sense.
>
> I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle
> of
> input register itself) to improve timing which we are struggling with. The
> design was showing malfunction pointing to that multicycle area.
> I removed the multicycle (only this change made to build) and it is now
> outputting correct expected spectrum.
>
> So I have to assume it was wrong multicycle but my own paper analysis
> indicated
> it could be multicycle.
>
> I believe the issue of multicycle must be automated by tools as part of
> timing
> analysis as it is indeed very hard to get right in many cases.

I find multicycle constraints to be a very simple issue.  As was 
explained, it is the paths that are constrained, not the registers.  So 
think in terms of the paths.

You have multicycle paths ending at some registers.  These paths need to 
be constrained with the correct time values.  The register enables (or 
write enables in your case) are still single clock cycle paths.  So you 
need to make sure the enables are constrained with the single clock 
period.  If you apply the longer, multicycle constraint to the enable 
paths, you may well end up with misaligned enables and data because of 
excessive path delays.  That is all there is to "multicycle" timing 
constraints.

But of course the devil is in the details.

I don't know what tools you are using and I'm not familiar with every 
tool family, so I likely couldn't give you detailed info on just how to 
apply timing constraints in your case.

What was said about the tools not being too smart about verifying timing 
constraints is, in my opinion, a major shortcoming of the tools.  We 
have powerful tools to verify our logic and our timing... but not the 
timing constraints which drive the timing analysis.  Everything about 
engineering is verification.  So I find it odd that you can't verify 
your timing constraints in any useful way.

If you are concerned that your timing constraints are working correctly, 
you can run a post-route simulation which will include timing.  This can 
help, but likely won't catch all potential issues.

Rick

Article: 154823
Subject: Re: Combination loops and false paths
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Jan 2013 21:21:22 -0500
Links: << >>  << T >>  << A >>
On 1/15/2013 12:54 AM, Rob Doyle wrote:
>
> I creating an FPGA implementation of a old DEC PDP-10 (KS-10,
> specifically) Mainframe Computer. Why? Because I always wanted one...
>
> The KS-10 was microcoded and used 10x am2901 4-bit slices in the ALU.
> At this stage, most of the instruction set diagnostics simulate correctly.
>
> When I synthesize this design using Xilinx ISE I get warnings about
> combinatorial loops involving the ALU - and an associated "Minimum
> period: 656.595ns (Maximum Frequency: 1.523MHz)" message...
>
> My understanding is that if combination loops really existed then the
> simulation wouldn't stabilize. I can't really add pipelining or
> registers to the design without affecting the microcode - and I don't
> want to do that.
>
> Most of the information that I've read about "false paths" assume two
> clocked processes not a combinatorial loop.
>
> Anyway. I'm not sure how to resolve this. I can mark the path as a
> false path but I think that it will ignore /all/ the timing (even the
> desired timing) through that path.
>
> What should I do?

Do you know why the tool is complaining?  Did you write the code 
describing the ALU?  Off the top of my head, I can't think of why an ALU 
would have a combinatorial loop.  It should have two input data busses, 
a number of control inputs, an output data bus and some output status 
signals.

I don't recall the details of the 2901 bit slice and my data books are 
not handy.  That's the problem with paper books, you can't just shove 
them on your hard drive...  Does this part have an internal register 
file?  Even so, that means the part would have a clock and not a 
combinatorial loop.  Maybe this is because of some internal bus that is 
shared in a way that looks like a loop even though it would never be 
used that way?

I may have to find my old AMD data book.  That could be an archeological 
dig!

Rick

Article: 154824
Subject: Re: Chisel as alternative HDL
From: Jecel <jecel@merlintec.com>
Date: Tue, 15 Jan 2013 21:35:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, January 15, 2013 8:30:10 PM UTC-2, Andy wrote:
> Diff (in CVS) does a horrible job! Try something capable like
> BeyondCompare. Even the comparison capapilities in TortoiseSVN are
> better than CVS/diff (I have not tried tortoiseCVS, it may be very
> similar to tortoiseSVN).

Thanks for the tip. I was talking about the diff tools normally found in Li=
nux. But my point was that while it is an easier problem to solve for text =
than for graphics, it isn't always well done for text and I hope I can get =
good results for graphics.

> Generally, if you work on a lot of small, one-man, one-off projects,
> these capabilities may not interest you or make you more productive.
> But when you work on large projects with several developers and a long
> product life-cycles, these capabilities rise to the top.

Agreed.

> Also, I think the relative preference of graphical/textual design
> entry has a lot to do with your design style. If you tend to be a very
> structural, concrete HW designer (e.g. if you think in terms of
> circuit elements that will do what you want), the schematic paradigm
> probably works great.

Though the sources that Sun released for its various processors were text-o=
nly Verilog, they are essentially a netlist of very low level primitives th=
at they defined themselves. I found this very hard to understand compared t=
o a more behavioral and higher level description. It might have evolved fro=
m a previous visual development method, as you said.

> If on the other hand, you prefer designing at higher levels of
> abstraction, and focus on the intended behavior of the design, along
> with throughput and latency, then a textual paradigm works better.
> Sure, there is still plenty of structure in even an abstract,
> behavioral (yet synthesizeable) design of any size/complexity, but
> abstracting interfaces using custom, aggregate data types (records,
> arrays, arrays of arrays, arrays of records, etc.) reduces the
> tediousness of the coding, and improves readability and
> maintainability.

While generators (parameterized IP in general, actually) are really awkward=
 to represent visually, I don't think any of the things you mentioned is a =
problem that only text can solve.

-- Jecel



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