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
2019JanFebMar2019

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 160775

Article: 160775
Subject: Re: New(ish) FPGA Company
From: Mike Perkins <spam@spam.com>
Date: Mon, 26 Nov 2018 15:51:37 +0000
Links: << >>  << T >>  << A >>
On 26/11/2018 08:46, already5chosen@yahoo.com wrote:
> On Monday, November 26, 2018 at 3:04:29 AM UTC+2,
> gnuarm.del...@gmail.com wrote:
>> On Sunday, November 25, 2018 at 12:51:30 PM UTC-5,
>> already...@yahoo.com wrote:
>>> On Sunday, November 25, 2018 at 7:28:13 PM UTC+2,
>>> gnuarm.del...@gmail.com wrote:
>>>> On Sunday, November 25, 2018 at 10:49:31 AM UTC-5,
>>>> already...@yahoo.com wrote:
>>>>> On Sunday, November 25, 2018 at 4:28:42 PM UTC+2,
>>>>> gnuarm.del...@gmail.com wrote:
>>>>>> On Saturday, November 24, 2018 at 3:12:01 PM UTC-5,
>>>>>> already...@yahoo.com wrote:
>>>>>>> On Saturday, November 10, 2018 at 7:39:55 PM UTC+2,
>>>>>>> gnuarm.del...@gmail.com wrote:
>>>>>>>> On Sunday, November 4, 2018 at 8:01:22 PM UTC-5,
>>>>>>>> gnuarm.del...@gmail.com wrote:
>>>>>>>>> I hadn't heard of this company before.  They seem to
>>>>>>>>> be making a number of FPGA devices.  Unfortunately
>>>>>>>>> all the docs are in Chinese.  Anyone know much about
>>>>>>>>> them?
>>>>>>>>> 
>>>>>>>>> http://www.anlogic.com/
>>>>>>>>> 
>>>>>>>>> Google can translate the web pages, but not the data
>>>>>>>>> sheets.
>>>>>>>>> 
>>>>>>>>> Rick C.
>>>>>>>> 
>>>>>>>> I'm a bit surprised at the lack of response...
>>>>>>>> hello...  Is this mike on?
>>>>>>>> 
>>>>>>>> I would have thought FPGA people might get excited
>>>>>>>> about a 16 kLUT FPGA with an embedded MCU for under
>>>>>>>> $10.  I am... sort of.  But I haven't started my
>>>>>>>> Chinese lessons yet.
>>>>>>>> 
>>>>>>>> Rick C.
>>>>>>> 
>>>>>>> No, I am not excited. 10CL016 is 17 USD on digikey in
>>>>>>> quantity of 1. Which probably means pretty close to 10
>>>>>>> USD in quantity of few 1000s. And if the quantity is
>>>>>>> lower than few 1000s then I probably don't care if it's
>>>>>>> 10 UDS or 17. 10CL016 comes with datasheet that I can
>>>>>>> read and with development tools that I can trust.
>>>>>>> 
>>>>>>> If you propose me "40 kLUT for 5 USD" then there is a
>>>>>>> chance that I can start to get excited.
>>>>>>> 
>>>>>>> BTW, as far as variable cost goes "40 kLUT for 5 USD" is
>>>>>>> pretty easy at 28nm or better. The problem here is how do
>>>>>>> you recover NRE. One have to sell more than 10M units.
>>>>>>> Probably much more.
>>>>>> 
>>>>>> How about 10k LUTs for $3.29 @500, data sheet in English?
>>>>>> 
>>>>>> https://lcsc.com/product-detail/CPLD-FPGA_AG10KF256_C133764.html
>>>>>>
>>>>>>
>>>>>> 
Is that at all interesting?
>>>>>> 
>>>>>> Rick C.
>>>>>> 
>>>>>> Tesla referral code - https://ts.la/richard11209
>>>>> 
>>>>> Looks like a clone of EP4CE10 == 10CL010. It could be
>>>>> interesting if they are compatible at bitstream level.
>>>>> Otherwise - less so.
>>>>> 
>>>>> But despite practicality I wouldn't count a manufacturer that
>>>>> managed to clone 9 years old Altera chip as new(ish) FPGA
>>>>> Company.
>>>> 
>>>> Why is bitstream compatibility between two Asian company
>>>> products important?
>>>> 
>>>> Rick C.
>>>> 
>>>> Tesla referral code + https://ts.la/richard11209
>>> 
>>> Since when Altera/Intel is Asian company?
>> 
>> Ok, it's official.  We are not having the same conversation.
>> 
>> Rick C.
>> 
>> Tesla referral code -- https://ts.la/richard11209
> 
> I suspect, we are not belonging to the same branch of the
> Multiverse. In our branch we have thingies called "web search
> engines". The most popular of them is called "google". It's so
> popular that its name became a verb.

What are you trying to prove.

You've said Altera/Intel is Asian company.

> Comparing datasheets it's also pretty easy to
> come to conclusion that AG10KF256 is the same chip as EP4CE10F256. 
> That's how it works in (on?) our branch of the Multiverse. But yours
> is probably different.

I would be reluctant to make that assumption without some further 
evidence. I've used your google and I haven't come across any article or 
claim to say they have the same bit stream.

If you find some I will be happy to eat humble pie.


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 160776
Subject: Re: New(ish) FPGA Company
From: already5chosen@yahoo.com
Date: Mon, 26 Nov 2018 09:12:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Monday, November 26, 2018 at 5:51:40 PM UTC+2, Mike Perkins wrote:
> On 26/11/2018 08:46, already5chosen@yahoo.com wrote:
> > On Monday, November 26, 2018 at 3:04:29 AM UTC+2,
> > gnuarm.del...@gmail.com wrote:
> >> On Sunday, November 25, 2018 at 12:51:30 PM UTC-5,
> >> already...@yahoo.com wrote:
> >>> On Sunday, November 25, 2018 at 7:28:13 PM UTC+2,
> >>> gnuarm.del...@gmail.com wrote:
> >>>> On Sunday, November 25, 2018 at 10:49:31 AM UTC-5,
> >>>> already...@yahoo.com wrote:
> >>>>> On Sunday, November 25, 2018 at 4:28:42 PM UTC+2,
> >>>>> gnuarm.del...@gmail.com wrote:
> >>>>>> On Saturday, November 24, 2018 at 3:12:01 PM UTC-5,
> >>>>>> already...@yahoo.com wrote:
> >>>>>>> On Saturday, November 10, 2018 at 7:39:55 PM UTC+2,
> >>>>>>> gnuarm.del...@gmail.com wrote:
> >>>>>>>> On Sunday, November 4, 2018 at 8:01:22 PM UTC-5,
> >>>>>>>> gnuarm.del...@gmail.com wrote:
> >>>>>>>>> I hadn't heard of this company before.  They seem to
> >>>>>>>>> be making a number of FPGA devices.  Unfortunately
> >>>>>>>>> all the docs are in Chinese.  Anyone know much about
> >>>>>>>>> them?
> >>>>>>>>> 
> >>>>>>>>> http://www.anlogic.com/
> >>>>>>>>> 
> >>>>>>>>> Google can translate the web pages, but not the data
> >>>>>>>>> sheets.
> >>>>>>>>> 
> >>>>>>>>> Rick C.
> >>>>>>>> 
> >>>>>>>> I'm a bit surprised at the lack of response...
> >>>>>>>> hello...  Is this mike on?
> >>>>>>>> 
> >>>>>>>> I would have thought FPGA people might get excited
> >>>>>>>> about a 16 kLUT FPGA with an embedded MCU for under
> >>>>>>>> $10.  I am... sort of.  But I haven't started my
> >>>>>>>> Chinese lessons yet.
> >>>>>>>> 
> >>>>>>>> Rick C.
> >>>>>>> 
> >>>>>>> No, I am not excited. 10CL016 is 17 USD on digikey in
> >>>>>>> quantity of 1. Which probably means pretty close to 10
> >>>>>>> USD in quantity of few 1000s. And if the quantity is
> >>>>>>> lower than few 1000s then I probably don't care if it's
> >>>>>>> 10 UDS or 17. 10CL016 comes with datasheet that I can
> >>>>>>> read and with development tools that I can trust.
> >>>>>>> 
> >>>>>>> If you propose me "40 kLUT for 5 USD" then there is a
> >>>>>>> chance that I can start to get excited.
> >>>>>>> 
> >>>>>>> BTW, as far as variable cost goes "40 kLUT for 5 USD" is
> >>>>>>> pretty easy at 28nm or better. The problem here is how do
> >>>>>>> you recover NRE. One have to sell more than 10M units.
> >>>>>>> Probably much more.
> >>>>>> 
> >>>>>> How about 10k LUTs for $3.29 @500, data sheet in English?
> >>>>>> 
> >>>>>> https://lcsc.com/product-detail/CPLD-FPGA_AG10KF256_C133764.html
> >>>>>>
> >>>>>>
> >>>>>> 
> Is that at all interesting?
> >>>>>> 
> >>>>>> Rick C.
> >>>>>> 
> >>>>>> Tesla referral code - https://ts.la/richard11209
> >>>>> 
> >>>>> Looks like a clone of EP4CE10 == 10CL010. It could be
> >>>>> interesting if they are compatible at bitstream level.
> >>>>> Otherwise - less so.
> >>>>> 
> >>>>> But despite practicality I wouldn't count a manufacturer that
> >>>>> managed to clone 9 years old Altera chip as new(ish) FPGA
> >>>>> Company.
> >>>> 
> >>>> Why is bitstream compatibility between two Asian company
> >>>> products important?
> >>>> 
> >>>> Rick C.
> >>>> 
> >>>> Tesla referral code + https://ts.la/richard11209
> >>> 
> >>> Since when Altera/Intel is Asian company?
> >> 
> >> Ok, it's official.  We are not having the same conversation.
> >> 
> >> Rick C.
> >> 
> >> Tesla referral code -- https://ts.la/richard11209
> > 
> > I suspect, we are not belonging to the same branch of the
> > Multiverse. In our branch we have thingies called "web search
> > engines". The most popular of them is called "google". It's so
> > popular that its name became a verb.
> 
> What are you trying to prove.
> 
> You've said Altera/Intel is Asian company.
> 

Reread the conversation. I never said that. 

> > Comparing datasheets it's also pretty easy to
> > come to conclusion that AG10KF256 is the same chip as EP4CE10F256. 
> > That's how it works in (on?) our branch of the Multiverse. But yours
> > is probably different.
> 
> I would be reluctant to make that assumption without some further 
> evidence. I've used your google and I haven't come across any article or 
> claim to say they have the same bit stream.

I didn't say that either. I wondered, if it is the same bit stream or not.
The chip is obviously the same design, but it is possible that they made small modification to cause bit stream to be incompatible. For example, for legal reasons.

> 
> If you find some I will be happy to eat humble pie.
> 
> 
> -- 
> Mike Perkins
> Video Solutions Ltd
> www.videosolutions.ltd.uk


Article: 160777
Subject: Re: Now - not so new cheaper FPGAs
From: gnuarm.deletethisbit@gmail.com
Date: Mon, 26 Nov 2018 10:03:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, January 27, 2018 at 3:02:34 PM UTC-5, Kevin Bowling wrote:
> On 01/10/18 11:32, rickman wrote:
> > I have used the Lattice XP3 FPGAs in a design I've made a lot of money=
=20
> > from. =C2=A0The parts have gone EOL but Arrow bought some 70,000+ and i=
s=20
> > still trying to get rid of them.=C2=A0 Seems they over estimated the ma=
rket. =20
> > I had to pay a higher price to them in 2016 than I paid when they were=
=20
> > in production (~$10) but now they are going for around $5-$6 depending=
=20
> > on quantity and they still have 65,000.=C2=A0 lol
> >=20
> >=20
>=20
> How do you like the Lattice tool chain compared to other FPGA vendors?

I don't see where I ever replied to this post.  Sorry.=20

In case it is still relevant...

I like the Lattice tools ok.  They use Synplify for synthesis and Active HD=
L for simulation.  I've never found an automatic way to setup projects in a=
ll three (the third one is the Lattice IDE itself which includes a Lattice =
synth tool I believe) in one blow.  So I have to create a Lattice project, =
then when I want to simulate I have to create an AHDL project. =20

I can be a little dense about such things.  When they hide so much behind t=
he GUI it is hard for me to tell what is ending up where and why I want thi=
ngs to be written where on the disk.  I'd like to see my source files at a =
highest level directory and everything else hidden in subs.  But they seem =
to want to do it bassackwards with the source hidden in a subdirectory and =
their pointless (to me) files at the top of each project.=20

I believe all the vendors are the same in this regard.  Am I mistaken? =20

Otherwise the tools seem fine.  I'm not a big guy on demanding a lot from t=
he tools.  To me FPGA tools are like my 20 year old truck.  Go, stop, don't=
 use too much gas.  That's pretty much all it needs to do.  The rest is jus=
t icing on the cake.=20

  Rick C.=20

  Tesla referral code - https://ts.la/richard11209

Article: 160778
Subject: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 27 Nov 2018 08:42:41 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

    CLK  = Cyclic N MHz clock
    BUSY = Asserted by various logic units when busy
    BRST = ~CLK
    CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

         __    __    __    __    __    __    __    __    __
CLK   __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__
                   ______
BUSY  ____________|      |____________________________________
      __    __    __    __    __    __    __    __    __    __
BRST    |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  

      __    __    __          __    __    __    __    __    __
CLK2    |__|  |__|  |________|  |__|  |__|  |__|  |__|  |__|  
                       held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.

-- 
Rick C. Hodgin

Article: 160779
Subject: Re: Periodically delayed clock
From: lasselangwadtchristensen@gmail.com
Date: Tue, 27 Nov 2018 09:36:09 -0800 (PST)
Links: << >>  << T >>  << A >>
tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
> I'm preparing designs for a CPU that will be coded in Verilog on
> a Terasic Cyclone V GX starter kit dev board.
> 
> I have a clock running at N MHz, and I have some logic that may
> take longer than the allotted time to complete (as N increases
> and the time to complete the logic each cycle decreases).
> 
> Rather than re-design my logic to use pipeline stages, I would
> like to do something like add a BUSY flag that would be raised
> when various logic units are busy, and lowered when they're no
> longer busy, so the clock is held before the next cycle actually
> triggers.
> 
> Would something as simple as this work (using an input clock,
> busy, busy reset, and an output clock2 that drives the system):
> 
>     CLK  = Cyclic N MHz clock
>     BUSY = Asserted by various logic units when busy
>     BRST = ~CLK
>     CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):
> 
>          __    __    __    __    __    __    __    __    __
> CLK   __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__
>                    ______
> BUSY  ____________|      |____________________________________
>       __    __    __    __    __    __    __    __    __    __
> BRST    |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  
> 
>       __    __    __          __    __    __    __    __    __
> CLK2    |__|  |__|  |________|  |__|  |__|  |__|  |__|  |__|  
>                        held
> 
> It would also seem I need to trigger each test to go high only
> on @negedge CLK so there are not partial clocks triggered, and
> that it would need to track @negedge BRST for going low.
> 
> Is there an easier / different way to do this?
> 
> Thank you in advance.
> 

don't gate the clock unless you really really have to, it is a recipe for headaches 

clock everything on the same clock and use a clock enable instead




Article: 160780
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 27 Nov 2018 10:13:21 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail.c=
om wrote:
> tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
> > I'm preparing designs for a CPU that will be coded in Verilog on
> > a Terasic Cyclone V GX starter kit dev board.
> >=20
> > I have a clock running at N MHz, and I have some logic that may
> > take longer than the allotted time to complete (as N increases
> > and the time to complete the logic each cycle decreases).
> >=20
> > Rather than re-design my logic to use pipeline stages, I would
> > like to do something like add a BUSY flag that would be raised
> > when various logic units are busy, and lowered when they're no
> > longer busy, so the clock is held before the next cycle actually
> > triggers.
> >=20
> > Would something as simple as this work (using an input clock,
> > busy, busy reset, and an output clock2 that drives the system):
> >=20
> >     CLK  =3D Cyclic N MHz clock
> >     BUSY =3D Asserted by various logic units when busy
> >     BRST =3D ~CLK
> >     CLK2 =3D trigger clock (on ~CLK && ~BUSY && BRST):
> >=20
> >          __    __    __    __    __    __    __    __    __
> > CLK   __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__
> >                    ______
> > BUSY  ____________|      |____________________________________
> >       __    __    __    __    __    __    __    __    __    __
> > BRST    |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__| =20
> >=20
> >       __    __    __          __    __    __    __    __    __
> > CLK2    |__|  |__|  |________|  |__|  |__|  |__|  |__|  |__| =20
> >                        held
> >=20
> > It would also seem I need to trigger each test to go high only
> > on @negedge CLK so there are not partial clocks triggered, and
> > that it would need to track @negedge BRST for going low.
> >=20
> > Is there an easier / different way to do this?
> >=20
> > Thank you in advance.
> >=20
>=20
> don't gate the clock unless you really really have to, it is a recipe for=
 headaches=20
>=20
> clock everything on the same clock and use a clock enable instead

+1

Clock gating adds logic and delay to the clock path.  This makes timing ana=
lysis very hard to do and the automatic tools will all but give up.  Certai=
nly you won't be able to trust them anymore.  In your simulations the added=
 delays can muck up things as well. =20

As LL has said, use clock enables and multiple clock cycles.=20

  Rick C.=20

  Tesla referral code - https://ts.la/richard11209

Article: 160781
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 27 Nov 2018 11:12:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, November 27, 2018 at 1:13:25 PM UTC-5, gnuarm.del...@gmail.com =
wrote:
> On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail=
.com wrote:
> > don't gate the clock unless you really really have to, it is a recipe f=
or headaches=20
> >=20
> > clock everything on the same clock and use a clock enable instead
>=20
> +1
>=20
> Clock gating adds logic and delay to the clock path.  This makes timing a=
nalysis very hard to do and the automatic tools will all but give up.  Cert=
ainly you won't be able to trust them anymore.  In your simulations the add=
ed delays can muck up things as well. =20
>=20
> As LL has said, use clock enables and multiple clock cycles.=20

LL, Rick C, thank you for your reply.

I'm not sure what "clock enables" means.  Is there an example?

--=20
Rick C. Hodgin

Article: 160782
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 27 Nov 2018 13:05:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
> On Tuesday, November 27, 2018 at 1:13:25 PM UTC-5, gnuarm.del...@gmail.co=
m wrote:
> > On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gma=
il.com wrote:
> > > don't gate the clock unless you really really have to, it is a recipe=
 for headaches=20
> > >=20
> > > clock everything on the same clock and use a clock enable instead
> >=20
> > +1
> >=20
> > Clock gating adds logic and delay to the clock path.  This makes timing=
 analysis very hard to do and the automatic tools will all but give up.  Ce=
rtainly you won't be able to trust them anymore.  In your simulations the a=
dded delays can muck up things as well. =20
> >=20
> > As LL has said, use clock enables and multiple clock cycles.=20
>=20
> LL, Rick C, thank you for your reply.
>=20
> I'm not sure what "clock enables" means.  Is there an example?

FFs can have enables on them so they don't take action until the enable is =
high.  In VHDL code it looks like this...

if (rising_edge(fast_clk)) then=20
  if (clock_enable_a =3D '1') then
    Q_out <=3D D_in;
  end if;
end if;

You can use separate clock enables for separate sections of your circuit as=
 needed.  The clock enables are treated like any other logic circuit in you=
r design with timing constraints of 1 clock cycle.  The logic feeding the D=
 input to an clock enabled FF only needs to be constrained as the clock ena=
ble logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the o=
peration of your design.=20

  Rick C.=20

  Tesla referral code + https://ts.la/richard11209

Article: 160783
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Tue, 27 Nov 2018 13:24:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, November 27, 2018 at 4:05:54 PM UTC-5, gnuarm.del...@gmail.com =
wrote:
> On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
> > I'm not sure what "clock enables" means.  Is there an example?
>=20
> FFs can have enables on them so they don't take action until the enable i=
s high.  In VHDL code it looks like this...
>=20
> if (rising_edge(fast_clk)) then=20
>   if (clock_enable_a =3D '1') then
>     Q_out <=3D D_in;
>   end if;
> end if;
>=20
> You can use separate clock enables for separate sections of your circuit =
as needed.  The clock enables are treated like any other logic circuit in y=
our design with timing constraints of 1 clock cycle.  The logic feeding the=
 D input to an clock enabled FF only needs to be constrained as the clock e=
nable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the=
 operation of your design.=20

Part of my goals on this project are to create a static design that can be =
clocked down to 0 MHz and still maintain it state, to clock at 1 Hz and sti=
ll work, to clock on a mechanical external trigger, and to run on the vario=
us system clocks.

My thinking has been that if I'm able to get it working properly at my targ=
et clock speed, then everything else should work if I underclock it, and ev=
en bring it down to a halt.

With such a design, would the ability to have variable clock pulse widths s=
till be something to be avoided?  Or is the whole idea of such a wildly var=
iable clock speed a pipe dream? :-)

--=20
Rick C. Hodgin

Article: 160784
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 27 Nov 2018 13:35:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, November 27, 2018 at 4:24:16 PM UTC-5, Rick C. Hodgin wrote:
> On Tuesday, November 27, 2018 at 4:05:54 PM UTC-5, gnuarm.del...@gmail.co=
m wrote:
> > On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote=
:
> > > I'm not sure what "clock enables" means.  Is there an example?
> >=20
> > FFs can have enables on them so they don't take action until the enable=
 is high.  In VHDL code it looks like this...
> >=20
> > if (rising_edge(fast_clk)) then=20
> >   if (clock_enable_a =3D '1') then
> >     Q_out <=3D D_in;
> >   end if;
> > end if;
> >=20
> > You can use separate clock enables for separate sections of your circui=
t as needed.  The clock enables are treated like any other logic circuit in=
 your design with timing constraints of 1 clock cycle.  The logic feeding t=
he D input to an clock enabled FF only needs to be constrained as the clock=
 enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to t=
he operation of your design.=20
>=20
> Part of my goals on this project are to create a static design that can b=
e clocked down to 0 MHz and still maintain it state, to clock at 1 Hz and s=
till work, to clock on a mechanical external trigger, and to run on the var=
ious system clocks.
>=20
> My thinking has been that if I'm able to get it working properly at my ta=
rget clock speed, then everything else should work if I underclock it, and =
even bring it down to a halt.
>=20
> With such a design, would the ability to have variable clock pulse widths=
 still be something to be avoided?  Or is the whole idea of such a wildly v=
ariable clock speed a pipe dream? :-)

Absolutely avoid variable width clock pulses for the reasons given.  Clock =
enables are the perfect way to slow your speed, enabling the design only on=
 the clock cycles you wish to advance the processing.  By removing the enab=
le the entire design stops.  Raise the enable for one clock cycle and the d=
esign advances one step.=20

It is always good to consider how you will debug a design in the chip.  But=
 you should be testing in simulation to get rid of 99.99% of the bugs befor=
e you ever load it into an FPGA.=20

  Rick C.=20

  Tesla referral code -- https://ts.la/richard11209

Article: 160785
Subject: Re: Periodically delayed clock
From: HT-Lab <hans64@htminuslab.com>
Date: Wed, 28 Nov 2018 10:01:15 +0000
Links: << >>  << T >>  << A >>
On 27/11/2018 17:36, lasselangwadtchristensen@gmail.com wrote:
> tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
>> I'm preparing designs for a CPU that will be coded in Verilog on
>> a Terasic Cyclone V GX starter kit dev board.
>>
>> I have a clock running at N MHz, and I have some logic that may
>> take longer than the allotted time to complete (as N increases
>> and the time to complete the logic each cycle decreases).
>>
>> Rather than re-design my logic to use pipeline stages, I would
>> like to do something like add a BUSY flag that would be raised
>> when various logic units are busy, and lowered when they're no
>> longer busy, so the clock is held before the next cycle actually
>> triggers.
>>
>> Would something as simple as this work (using an input clock,
>> busy, busy reset, and an output clock2 that drives the system):
>>
>>      CLK  = Cyclic N MHz clock
>>      BUSY = Asserted by various logic units when busy
>>      BRST = ~CLK
>>      CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):
>>
>>           __    __    __    __    __    __    __    __    __
>> CLK   __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__
>>                     ______
>> BUSY  ____________|      |____________________________________
>>        __    __    __    __    __    __    __    __    __    __
>> BRST    |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|
>>
>>        __    __    __          __    __    __    __    __    __
>> CLK2    |__|  |__|  |________|  |__|  |__|  |__|  |__|  |__|
>>                         held
>>
>> It would also seem I need to trigger each test to go high only
>> on @negedge CLK so there are not partial clocks triggered, and
>> that it would need to track @negedge BRST for going low.
>>
>> Is there an easier / different way to do this?
>>
>> Thank you in advance.
>>
> 
> don't gate the clock unless you really really have to, it is a recipe for headaches
> 
> clock everything on the same clock and use a clock enable instead
> 
> 
> 
I also agree with statement,however for completeness most (if not all) 
modern synthesis tools will remove the AND gate in front of the clock 
input and re-connect the "gate signal" to the FF's CE pin (there are 
other constructs as well).

FPGA are used for ASIC prototyping and for this reason most synthesis 
tools can handle ASIC coding styles like gate clocks, ripple counters, 
clock muxes and they even convert DesignWare blocks.

My additional advice to Rick would be spend some time on adding pipeline 
stages and simply stall the units if no input data is available or feed 
them with NOPs. If you want to give units more clock cycles delays then 
look into multicyle path constructs and constraints (which can sometimes 
be a real pain). You might also want to add some assertions (on the path 
control logic) to confirm the path is always multicyle (>1 clock cycle).

Good luck,
Hans
www.ht-lab.com

Article: 160786
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 07:43:11 -0800 (PST)
Links: << >>  << T >>  << A >>
How would I implement a clock enable differently than I'm doing here?


    CLK  = Cyclic N MHz clock 
    BUSY = Asserted by various logic units when busy 
    BRST = ~CLK 
    CLK2 = trigger clock (on ~CLK && ~BUSY && BRST): 

         __    __    __    __    __    __    __    __    __ 
CLK   __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__ 
                   ______ 
BUSY  ____________|      |____________________________________ 
      __    __    __    __    __    __    __    __    __    __ 
BRST    |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|   

      __    __    __          __    __    __    __    __    __ 
CLK2    |__|  |__|  |________|  |__|  |__|  |__|  |__|  |__|   
                       held 

It's like my BUSY signal would effectively be ~ENABLE, wouldn't it?
CLK still runs consistent and periodic, but the advances are triggered
off CLK2, which could be renamed TRIGGER or something.

??

-- 
Rick C. Hodgin

Article: 160787
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 28 Nov 2018 08:32:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:
> How would I implement a clock enable differently than I'm doing here?
> 
> 
>     CLK  = Cyclic N MHz clock 
>     BUSY = Asserted by various logic units when busy 
>     BRST = ~CLK 
>     CLK2 = trigger clock (on ~CLK && ~BUSY && BRST): 
> 
>          __    __    __    __    __    __    __    __    __ 
> CLK   __|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__ 
>                    ______ 
> BUSY  ____________|      |____________________________________ 
>       __    __    __    __    __    __    __    __    __    __ 
> BRST    |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|   
> 
>       __    __    __          __    __    __    __    __    __ 
> CLK2    |__|  |__|  |________|  |__|  |__|  |__|  |__|  |__|   
>                        held 
> 
> It's like my BUSY signal would effectively be ~ENABLE, wouldn't it?
> CLK still runs consistent and periodic, but the advances are triggered
> off CLK2, which could be renamed TRIGGER or something.
> 
> ??
> 
> -- 
> Rick C. Hodgin

I don't see an implementation.  I see a timing diagram where you appear to be gating the clock.  I'm not sure what you are thinking or what you are trying to say. 

I gave you a snippet of code that showed a clock enable.  Did you understand the code?  How about if you write some code that will implement your idea and compare that to the code I gave you? 

  Rick C. 

  Tesla referral code -+ https://ts.la/richard11209

Article: 160788
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 09:22:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 11:32:07 AM UTC-5, gnuarm.del...@gmail.com wrote:
> On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:
>
> >     CLK2 = trigger clock (on ~CLK && ~BUSY && BRST): 
>
> I don't see an implementation.  I see a timing diagram where you appear to be gating the clock.  I'm not sure what you are thinking or what you are trying to say.

The CLK2 output is the trigger for the next event.

> I gave you a snippet of code that showed a clock enable.  Did you understand the code?  How about if you write some code that will implement your idea and compare that to the code I gave you? 

The little bit above is close to the code, but there are some caveats on which edge to trigger.

I'll put on my thinking cap and get back to you.

-- 
Rick C. Hodgin

Article: 160789
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 28 Nov 2018 09:43:58 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 12:22:12 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, November 28, 2018 at 11:32:07 AM UTC-5, gnuarm.del...@gmail=
.com wrote:
> > On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wr=
ote:
> >
> > >     CLK2 =3D trigger clock (on ~CLK && ~BUSY && BRST):=20
> >
> > I don't see an implementation.  I see a timing diagram where you appear=
 to be gating the clock.  I'm not sure what you are thinking or what you ar=
e trying to say.
>=20
> The CLK2 output is the trigger for the next event.

You seem to be speaking in your own terms.  I don't know what a "trigger" m=
eans.  Digital design signals generally have clocks and logic.  Logic can b=
e clock enables or data.  By "trigger" do you mean a clock enable?  If you =
are talking about a clock enable, it should not be generated by gating the =
clock. =20

Let me make this simple.  NEVER GATE THE CLOCK when working in FPGAs.  In f=
act, I will make this even more general, NEVER USE THE CLOCK AS PART OF THE=
 LOGIC.  There may be a very few cases where it makes sense to use the cloc=
k as part of your logic, but they are exceedingly few and you have to under=
stand all the implications.  I'm not willing to go through all the importan=
t issues with someone who is dealing with the basics of logic design.  So f=
or now learn the basics, then maybe you can learn the rest later.=20

So for now consider all logic to be the same, based on other logic signals =
only and not the clock.  This also applies to your busy reset. =20


> > I gave you a snippet of code that showed a clock enable.  Did you under=
stand the code?  How about if you write some code that will implement your =
idea and compare that to the code I gave you?=20
>=20
> The little bit above is close to the code, but there are some caveats on =
which edge to trigger.
>=20
> I'll put on my thinking cap and get back to you.

Don't try to worry about "which clock edge".  Always work with the positive=
 edge until you better understand what you are doing.  Like using the clock=
 in logic, there are few situations where working on the opposite edge of t=
he clock will gain you any advantages and it adds significantly to the issu=
es of verifying timing.=20

The clock should be used for one thing only, to drive the clock input of FF=
s, preferably all triggered from the same edge.=20

  Rick C.=20

  Tesla referral code +- https://ts.la/richard11209

Article: 160790
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 10:13:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail.c=
om wrote:
> You seem to be speaking in your own terms.  I don't know what a "trigger"=
 means.

The trigger is the signal given to advance the stepper.  Here is an illustr=
ated example from a reference CPU design written for the purposes of instru=
ction and education:

    Scott CPU -- Begins at 2:33 into the video.
    Click the link directly to advance to that point:

    https://www.youtube.com/watch?v=3DNKYgZH7SBjk&t=3D2m33s

I already have a five-stage pipeline.  As clock speeds go faster, some oper=
ations will take longer to compute than the clock allows.  It is only on th=
ose stages that I want there to be a delay here.

So my thinking has been:  I'll take the clock, which is steady at whatever =
clock speed it's running, and then not use it as input into that stepper co=
mponent, but will introduce delays to consume an extra clock cycle where re=
quired due to the delays on certain instructions.

I apologize for using my own terminology.  I have never taken classes on th=
is subject.  This is all me figuring out how it should be done in logic, an=
d then trying (with much difficulty) to translate it into the needs of real=
-world tools.  I also encounter resistance when I approach others with my t=
hinking, rather than the hard and fast specs / terms other people are used =
to hearing.  To be honest, it's a little bit frustrating for me because I h=
ave been able to figure all of this out on my own, and what I'm getting los=
t on is the mechanics of making it happen in real-world tools, and not the =
theory underlying it.

--=20
Rick C. Hodgin

Article: 160791
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 28 Nov 2018 10:40:59 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 1:13:21 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail=
.com wrote:
> > You seem to be speaking in your own terms.  I don't know what a "trigge=
r" means.
>=20
> The trigger is the signal given to advance the stepper.  Here is an illus=
trated example from a reference CPU design written for the purposes of inst=
ruction and education:
>=20
>     Scott CPU -- Begins at 2:33 into the video.
>     Click the link directly to advance to that point:
>=20
>     https://www.youtube.com/watch?v=3DNKYgZH7SBjk&t=3D2m33s
>=20
> I already have a five-stage pipeline.  As clock speeds go faster, some op=
erations will take longer to compute than the clock allows.  It is only on =
those stages that I want there to be a delay here.
>=20
> So my thinking has been:  I'll take the clock, which is steady at whateve=
r clock speed it's running, and then not use it as input into that stepper =
component, but will introduce delays to consume an extra clock cycle where =
required due to the delays on certain instructions.
>=20
> I apologize for using my own terminology.  I have never taken classes on =
this subject.  This is all me figuring out how it should be done in logic, =
and then trying (with much difficulty) to translate it into the needs of re=
al-world tools.  I also encounter resistance when I approach others with my=
 thinking, rather than the hard and fast specs / terms other people are use=
d to hearing.  To be honest, it's a little bit frustrating for me because I=
 have been able to figure all of this out on my own, and what I'm getting l=
ost on is the mechanics of making it happen in real-world tools, and not th=
e theory underlying it.

Ok, you are trying to generate an output called "trigger".  You might try a=
nother name.  So what is your question? =20

Thinking in your own terms and names means you will find it hard to communi=
cate with others.  I have given you enough information to understand how to=
 delay your circuit using a clock enable.  Is there anything you don't unde=
rstand regarding what I have given you? =20

Personally I think your problem is you are trying to build an aircraft carr=
ier before you understand how to build a hinge.  It would be much better if=
 you tried working on much simpler projects and worked up to your massive C=
PU design.  But you are free to learn any way you want. =20

So what is your question?=20

  Rick C.=20

  Tesla referral code ++ https://ts.la/richard11209

Article: 160792
Subject: Re: Periodically delayed clock
From: lasselangwadtchristensen@gmail.com
Date: Wed, 28 Nov 2018 10:48:37 -0800 (PST)
Links: << >>  << T >>  << A >>
onsdag den 28. november 2018 kl. 19.13.21 UTC+1 skrev Rick C. Hodgin:
> On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail=
.com wrote:
> > You seem to be speaking in your own terms.  I don't know what a "trigge=
r" means.
>=20
> The trigger is the signal given to advance the stepper.  Here is an illus=
trated example from a reference CPU design written for the purposes of inst=
ruction and education:
>=20
>     Scott CPU -- Begins at 2:33 into the video.
>     Click the link directly to advance to that point:
>=20
>     https://www.youtube.com/watch?v=3DNKYgZH7SBjk&t=3D2m33s
>=20
> I already have a five-stage pipeline.  As clock speeds go faster, some op=
erations will take longer to compute than the clock allows.  It is only on =
those stages that I want there to be a delay here.
>=20
> So my thinking has been:  I'll take the clock, which is steady at whateve=
r clock speed it's running, and then not use it as input into that stepper =
component, but will introduce delays to consume an extra clock cycle where =
required due to the delays on certain instructions.
>=20
> I apologize for using my own terminology.  I have never taken classes on =
this subject.  This is all me figuring out how it should be done in logic, =
and then trying (with much difficulty) to translate it into the needs of re=
al-world tools.  I also encounter resistance when I approach others with my=
 thinking, rather than the hard and fast specs / terms other people are use=
d to hearing.  To be honest, it's a little bit frustrating for me because I=
 have been able to figure all of this out on my own, and what I'm getting l=
ost on is the mechanics of making it happen in real-world tools, and not th=
e theory underlying it.
>=20

I think you are meeting resistance because you are try to do things in a wa=
y=20
people learned long time ago was a bad idea, and that getting lost in the m=
echanics probably means you haven't quite figured it out.=20


all you need is clk and busy, don't gate the clock and only use rising edge


always@(posedge clk)
begin
  if(!bsy)
    cnt <=3D cnt + 1;
end
        _   _   _   _
clk ___| |_| |_| |_| |_
            ___
bsy _______|   |_______
    ___ ___ _______ ___=20
cnt _0_|_1_|_2_____|_3_




Article: 160793
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 10:52:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 1:48:41 PM UTC-5, lasselangwad...@gmail.=
com wrote:
> I think you are meeting resistance because you are try to do things in a =
way=20
> people learned long time ago was a bad idea, and that getting lost in the=
 mechanics probably means you haven't quite figured it out.

No doubt.  I don't have a mentor or tutor to help guide me, so I'm having t=
o do it all on my own.  I think in terms of ideal scenarios, and not practi=
cal real-world scenarios, and I have no doubts I'll get caught up in the tr=
anslation form the ideal into a real-world implementation.

> all you need is clk and busy, don't gate the clock and only use rising ed=
ge
>=20
> always@(posedge clk)
> begin
>   if(!bsy)
>     cnt <=3D cnt + 1;
> end
>         _   _   _   _
> clk ___| |_| |_| |_| |_
>             ___
> bsy _______|   |_______
>     ___ ___ _______ ___=20
> cnt _0_|_1_|_2_____|_3_

I'll work on getting correct technology.  And I ask for a little grace unti=
l I get it all sorted please. :-)

Thank you.

--=20
Rick C. Hodgin

Article: 160794
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 11:14:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> Thinking in your own terms and names means you will find it hard to communicate with others.

I agree.  I'll work on it.  Will you help me get there?

> I have given you enough information to understand how to delay your circuit using a clock enable.  Is there anything you don't understand regarding what I have given you?

    if (rising_edge(fast_clk)) then 
      if (clock_enable_a = '1') then 
        Q_out <= D_in; 
      end if; 
    end if;

What is D_in here?

-- 
Rick C. Hodgin

Article: 160795
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 28 Nov 2018 11:19:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 2:14:05 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > Thinking in your own terms and names means you will find it hard to communicate with others.
> 
> I agree.  I'll work on it.  Will you help me get there?
> 
> > I have given you enough information to understand how to delay your circuit using a clock enable.  Is there anything you don't understand regarding what I have given you?
> 
>     if (rising_edge(fast_clk)) then 
>       if (clock_enable_a = '1') then 
>         Q_out <= D_in; 
>       end if; 
>     end if;
> 
> What is D_in here?
> 
> -- 
> Rick C. Hodgin
 
         FF
     +--------+
     |        |
>----| D_in   |
     |        |
     |  Q_out |----> 
     |        |
>----|>       |
     |        |
     +--------+

Is this more clear? 

  Rick C. 

  Tesla referral code --- https://ts.la/richard11209

Article: 160796
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 11:42:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 2:19:21 PM UTC-5, gnuarm.del...@gmail.com wrote:
> On Wednesday, November 28, 2018 at 2:14:05 PM UTC-5, Rick C. Hodgin wrote:
> > On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > Thinking in your own terms and names means you will find it hard to communicate with others.
> > 
> > I agree.  I'll work on it.  Will you help me get there?
> > 
> > > I have given you enough information to understand how to delay your circuit using a clock enable.  Is there anything you don't understand regarding what I have given you?
> > 
> >     if (rising_edge(fast_clk)) then 
> >       if (clock_enable_a = '1') then 
> >         Q_out <= D_in; 
> >       end if; 
> >     end if;
> > 
> > What is D_in here?
> > 
> > -- 
> > Rick C. Hodgin
>  
>          FF
>      +--------+
>      |        |
> >----| D_in   |
>      |        |
>      |  Q_out |----> 
>      |        |
> >----|>       |
>      |        |
>      +--------+
> 
> Is this more clear? 

I understood the throughput.  I don't know what "FF" means, and I don't
know where D_in comes from.  What's it wired to?

-- 
Rick C. Hodgin

Article: 160797
Subject: Re: Periodically delayed clock
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 28 Nov 2018 11:49:18 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 2:42:35 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, November 28, 2018 at 2:19:21 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > On Wednesday, November 28, 2018 at 2:14:05 PM UTC-5, Rick C. Hodgin wrote:
> > > On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> > > > Thinking in your own terms and names means you will find it hard to communicate with others.
> > > 
> > > I agree.  I'll work on it.  Will you help me get there?
> > > 
> > > > I have given you enough information to understand how to delay your circuit using a clock enable.  Is there anything you don't understand regarding what I have given you?
> > > 
> > >     if (rising_edge(fast_clk)) then 
> > >       if (clock_enable_a = '1') then 
> > >         Q_out <= D_in; 
> > >       end if; 
> > >     end if;
> > > 
> > > What is D_in here?
> > > 
> > > -- 
> > > Rick C. Hodgin
> >  
> >          FF
> >      +--------+
> >      |        |
> > >----| D_in   |
> >      |        |
> >      |  Q_out |----> 
> >      |        |
> > >----|>       |
> >      |        |
> >      +--------+
> > 
> > Is this more clear? 
> 
> I understood the throughput.  I don't know what "FF" means, and I don't
> know where D_in comes from.  What's it wired to?
> 
> -- 
> Rick C. Hodgin

FF means Flip Flop, the basic element of storage in digital logic.  D_in comes from your logic.  It is any signal you want it to be.  

I don't know if we are simply having communication problems because you are not familiar with the most fundamental nomenclature of digital logic design or if you don't understand the concepts of digital logic.  I find both ideas equally implausible.  

What do you call a flip flop?  What would you use as the data input? 

  Rick C. 

  Tesla referral code --+ https://ts.la/richard11209

Article: 160798
Subject: Re: Periodically delayed clock
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 28 Nov 2018 12:06:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.co=
m wrote:
> FF means Flip Flop, the basic element of storage in digital logic.  D_in =
comes from your logic.  It is any signal you want it to be.
>
> I don't know if we are simply having communication problems because you a=
re not familiar with the most fundamental nomenclature of digital logic des=
ign or if you don't understand the concepts of digital logic.  I find both =
ideas equally implausible.

I understand concepts.  I even know flip-flop, but the FF abbreviation wasn=
't on my radar.

> What do you call a flip flop?  What would you use as the data input?

I have thought of them as bit storage.  And as I understand their use, they=
 are explicitly set to 0 or 1, and do not actually flip flop.  They maintai=
n the state specified as of the time of their last setting, so they output =
continually as a bit buffer.

I think D_in would be wired to my BUSY signal, and the SET input would be a=
sserted on each clock's rising edge.  This would consistently set the FF to=
 0 or 1 based on the BUSY input, and it would sustain throughout the entire=
 clock cycle, being re-SET each time to the new state.

--=20
Rick C. Hodgin

Article: 160799
Subject: Re: Periodically delayed clock
From: lasselangwadtchristensen@gmail.com
Date: Wed, 28 Nov 2018 12:21:32 -0800 (PST)
Links: << >>  << T >>  << A >>
onsdag den 28. november 2018 kl. 21.06.57 UTC+1 skrev Rick C. Hodgin:
> On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.=
com wrote:
> > FF means Flip Flop, the basic element of storage in digital logic.  D_i=
n comes from your logic.  It is any signal you want it to be.
> >
> > I don't know if we are simply having communication problems because you=
 are not familiar with the most fundamental nomenclature of digital logic d=
esign or if you don't understand the concepts of digital logic.  I find bot=
h ideas equally implausible.
>=20
> I understand concepts.  I even know flip-flop, but the FF abbreviation wa=
sn't on my radar.
>=20
> > What do you call a flip flop?  What would you use as the data input?
>=20
> I have thought of them as bit storage.  And as I understand their use, th=
ey are explicitly set to 0 or 1, and do not actually flip flop.  They maint=
ain the state specified as of the time of their last setting, so they outpu=
t continually as a bit buffer.
>=20
> I think D_in would be wired to my BUSY signal, and the SET input would be=
 asserted on each clock's rising edge.  This would consistently set the FF =
to 0 or 1 based on the BUSY input, and it would sustain throughout the enti=
re clock cycle, being re-SET each time to the new state.
>=20

rewind ....

the code was:

>     if (rising_edge(fast_clk)) then
>       if (clock_enable_a =3D '1') then
>         Q_out <=3D D_in;
>       end if;
>     end if;=20

that is a flopflip with clok enable; at every rising edge of fast_clk=20
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable
=20




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
2019JanFebMar2019

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