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 159550

Article: 159550
Subject: Re: Quad-Port BlockRAM in Virtex
From: Ameer Abdelhadi <ameer.abdelhadi@gmail.com>
Date: Tue, 13 Dec 2016 13:37:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, November 8, 2016 at 12:13:55 PM UTC-5, Kevin Neilson wrote:
> On Saturday, November 5, 2016 at 11:35:20 AM UTC-6, Guy Lemieux wrote:
> > There is a paper that describes your approach, published by my Ph.D. st=
udent Ameer Abdelhadi at FPGA2014. He has also extended it to include switc=
hed ports, where some ports can dynamically switch between read and write m=
ode at FCCM2016.
> >=20
> > http://ece.ubc.ca/~ameer/publications.html
> >=20
> > He has released the designs on GitHub under a permissive open source li=
cense.=20
> >=20
> > https://github.com/AmeerAbdelhadi/Switched-Multiported-RAM
> >=20
> > Guy
>=20
> Thanks; I enjoyed looking through the papers.  The idea of dynamically sw=
itching the write ports to reads is one I might need to use at some point.
>=20
> The main difference in my diagram is that I implemented part of the I-LVT=
 in the data RAMs.  For example, for a 2W/2R memory, you show the I-LVT RAM=
s as being 1 write, 3 reads.  My I-LVTs are 1 write, 1 read, with the rest =
of the I-LVT done in the data RAMs.  In my case, I need 69-wide BRAMs, and =
the BRAMs are 72 bits wide, so I have an extra 3 bits.  I use one of those =
bits as the I-LVT ("semaphore") bit.  When I do a read, I don't have to acc=
ess a separate I-LVT RAM.


Kevin, the method you mentioned is actually identical to the 2W/2R I-LVT (b=
oth binary-coded and thermometer-coded) from our FPGA2014 paper, with ONE m=
odification:
You store the BRAM outputs of the LVT in the data banks. After reading the =
data banks, these LVT bits will also be read as a meta-data, then the outpu=
t selectors will be extracted (the XOR's in your diagram). This will indeed=
 prevent replicating the LVT BRAMs; however, it incurs other *severe* probl=
ems:

1) Additional 2 cycles in the decision path!
The longest path of our I-LVT method passes through the LVT as follows:
1- Reading the I-LVT feedbacks
2- Rewriting the I-LVT
3- Reading the I-LVT to generate (through output extraction function) outpu=
t mux selectors.
With these three cycles, our I-LVT required a very complicated bypassing ci=
rcuitry to deal with even simple hazards as Write-After-Write.
Your solution adds two cycles in the selection path, one to rewrite the dat=
a banks with the I-LVT bits, and the second to read these bits (then extrac=
t the selectors). This solution requires caching to bypass this very long d=
ecision path, which will increase the BRAM overhead again.

In other words, the read mechanism of both methods is similar, but the outp=
ut mux selectors in your method are read from the data banks instead of the=
 LVT. Once a write happens, the output selectors will see the change after =
5 cycles (LVT feedback read -> LVT rewrite -> LVT read -> data banks write =
(selectors) -> data bank read (selectors)), whereas ours requires only 3 cy=
cles.

2) Modularity:
The additional bits can't accommodate bank selectors for every number of wr=
ite ports. For instance, you mentioned extra 3 bits in each BRAM line. Thes=
e 3 bits can code selectors for up to 8 write ports. For more than 8 write =
ports, the meta-data should be stored in additional BRAMs, which will furth=
er increase the BRAM consumption.

Anyhow, the I-LVT portion is minor compared to the data banks. For instance=
, in your diagram, you are using 140Kbits for the data banks and only 2Kbit=
s for the LVT. Our I-LVT requires only 2Kbits more for the I-LVT (only +1.5=
%), however, it eliminates the need for caching (as required by your soluti=
on).

Ameer
http://www.ece.ubc.ca/~ameer/

Article: 159551
Subject: Re: Linux OS for FPGA worth
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 14 Dec 2016 15:07:22 -0600
Links: << >>  << T >>  << A >>
Cecil Bayona wrote:

> I keep debating if I should start switching my PCs from Windows 10 to
> Linux, several of my main PCs are on Win 10 Preview, and Microsoft made
> it so you can't get off until the next non-preview release.
> 
> I play around with Lattice, and Xilinx FPGAs, I know Lattice has their
> Diamond software available for Linux, and Xilinx has Vivado and it's
> older software also available for Linux also, but I've read that it's
> difficult to get them to work with Linux.
> 
> I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has
> used with with either of that software and how difficult was it to get
> it working?
The oldest Xilinx Ise versions (10.1) won't run on a 64-bit Linux 
environment without more tweaking than I'm willing to invest.  The later 
versions 13.x 14.x seem to work fine on a 64-bit Ubuntu 12 system.

The download pods can be tricky to get running right.  Xilinx's own pod 
seems to be easy, the Digilent pod took a bit more effort.

Jon

Article: 159552
Subject: Re: Quad-Port BlockRAM in Virtex
From: Ameer Abdelhadi <ameer.abdelhadi@gmail.com>
Date: Fri, 16 Dec 2016 13:43:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, December 13, 2016 at 4:37:42 PM UTC-5, Ameer Abdelhadi wrote:
> On Tuesday, November 8, 2016 at 12:13:55 PM UTC-5, Kevin Neilson wrote:
> > On Saturday, November 5, 2016 at 11:35:20 AM UTC-6, Guy Lemieux wrote:
> > > There is a paper that describes your approach, published by my Ph.D. =
student Ameer Abdelhadi at FPGA2014. He has also extended it to include swi=
tched ports, where some ports can dynamically switch between read and write=
 mode at FCCM2016.
> > >=20
> > > http://ece.ubc.ca/~ameer/publications.html
> > >=20
> > > He has released the designs on GitHub under a permissive open source =
license.=20
> > >=20
> > > https://github.com/AmeerAbdelhadi/Switched-Multiported-RAM
> > >=20
> > > Guy
> >=20
> > Thanks; I enjoyed looking through the papers.  The idea of dynamically =
switching the write ports to reads is one I might need to use at some point=
.
> >=20
> > The main difference in my diagram is that I implemented part of the I-L=
VT in the data RAMs.  For example, for a 2W/2R memory, you show the I-LVT R=
AMs as being 1 write, 3 reads.  My I-LVTs are 1 write, 1 read, with the res=
t of the I-LVT done in the data RAMs.  In my case, I need 69-wide BRAMs, an=
d the BRAMs are 72 bits wide, so I have an extra 3 bits.  I use one of thos=
e bits as the I-LVT ("semaphore") bit.  When I do a read, I don't have to a=
ccess a separate I-LVT RAM.
>=20
>=20
> Kevin, the method you mentioned is actually identical to the 2W/2R I-LVT =
(both binary-coded and thermometer-coded) from our FPGA2014 paper, with ONE=
 modification:
> You store the BRAM outputs of the LVT in the data banks. After reading th=
e data banks, these LVT bits will also be read as a meta-data, then the out=
put selectors will be extracted (the XOR's in your diagram). This will inde=
ed prevent replicating the LVT BRAMs; however, it incurs other *severe* pro=
blems:
>=20
> 1) Additional 2 cycles in the decision path!
> The longest path of our I-LVT method passes through the LVT as follows:
> 1- Reading the I-LVT feedbacks
> 2- Rewriting the I-LVT
> 3- Reading the I-LVT to generate (through output extraction function) out=
put mux selectors.
> With these three cycles, our I-LVT required a very complicated bypassing =
circuitry to deal with even simple hazards as Write-After-Write.
> Your solution adds two cycles in the selection path, one to rewrite the d=
ata banks with the I-LVT bits, and the second to read these bits (then extr=
act the selectors). This solution requires caching to bypass this very long=
 decision path, which will increase the BRAM overhead again.
>=20
> In other words, the read mechanism of both methods is similar, but the ou=
tput mux selectors in your method are read from the data banks instead of t=
he LVT. Once a write happens, the output selectors will see the change afte=
r 5 cycles (LVT feedback read -> LVT rewrite -> LVT read -> data banks writ=
e (selectors) -> data bank read (selectors)), whereas ours requires only 3 =
cycles.
>=20
> 2) Modularity:
> The additional bits can't accommodate bank selectors for every number of =
write ports. For instance, you mentioned extra 3 bits in each BRAM line. Th=
ese 3 bits can code selectors for up to 8 write ports. For more than 8 writ=
e ports, the meta-data should be stored in additional BRAMs, which will fur=
ther increase the BRAM consumption.
>=20
> Anyhow, the I-LVT portion is minor compared to the data banks. For instan=
ce, in your diagram, you are using 140Kbits for the data banks and only 2Kb=
its for the LVT. Our I-LVT requires only 2Kbits more for the I-LVT (only +1=
.5%), however, it eliminates the need for caching (as required by your solu=
tion).
>=20
> Ameer
> http://www.ece.ubc.ca/~ameer/

BTW, our design is available online as an open source library. It's modular=
, parametrized, optimized for high performance and optimal resources consum=
ption, fully bypassed, and fully tested with a run-in-batch manager for sim=
ulation and synthesis.

Just download the Verilog, add it to your project, instantiate the IP modul=
e, change to your parameters (e.g. #reads, #writes, data width, RAM depth, =
bypassing...), and you're ready to go!

Open source libraries:
http://www.ece.ubc.ca/~ameer/opensource.html
https://github.com/AmeerAbdelhadi/

BRAM-based Multi-ported RAM from FPGA'14:
https://github.com/AmeerAbdelhadi/Multiported-RAM
Paper: http://www.ece.ubc.ca/~ameer/publications/Abdelhadi-Conference-2014F=
eb-FPGA2014-MultiportedRAM.pdf
Slides: http://www.ece.ubc.ca/~ameer/publications/Abdelhadi-Talk-2014Feb-FP=
GA2014-MultiportedRAM.pdf

Enjoy!

Article: 159553
Subject: Lattice Semiconductor $99 promo on several items
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Mon, 19 Dec 2016 08:45:28 -0800 (PST)
Links: << >>  << T >>  << A >>
If you're not on their mailing list, Lattice Semiconductor has some items
on sale through January 27, 2017 or as supplies last:

ECP5 Versa Development Kit ($199) now $89:

     http://www.latticesemi.com/Products/DevelopmentBoardsAndKits/ECP5VersaDevelopmentKit.aspx

ECP5-5G Versa Development Kit Side View	ECP5-5G Versa Development Kit
($249) now $99:

     http://www.latticesemi.com/Products/DevelopmentBoardsAndKits/ECP55GVersaDevKit.aspx

Connectivity IP Suite
Includes interface IP cores such as PCI Express, CPRI, JESD204B, DDR3
controller, Gigabit Ethernet MAC, etc. ($995) now $99:

     Check "IP Core" to see the list:
     http://www.latticesemi.com/Products/DesignSoftwareAndIP/IntellectualProperty.aspx

Lattice Diamond Design Software	Lattice Diamond Software ($895) now $99:

     http://www.latticesemi.com/Products/DesignSoftwareAndIP/FPGAandLDS/LatticeDiamond.aspx

Best regards,
Rick C. Hodgin

Article: 159554
Subject: Re: Quad-Port BlockRAM in Virtex
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 20 Dec 2016 16:09:35 -0800 (PST)
Links: << >>  << T >>  << A >>
> Kevin, the method you mentioned is actually identical to the 2W/2R I-LVT =
(both binary-coded and thermometer-coded) from our FPGA2014 paper, with ONE=
 modification:
> You store the BRAM outputs of the LVT in the data banks. After reading th=
e data banks, these LVT bits will also be read as a meta-data, then the out=
put selectors will be extracted (the XOR's in your diagram). This will inde=
ed prevent replicating the LVT BRAMs; however, it incurs other *severe* pro=
blems:

Ameer,
Thanks for the response.  Yes, there may be some latency disadvantages in m=
y approach.  For the cache that I need for the bypass logic, I use a Xilinx=
 dynamic SRL.  It's the same size and speed whether or not the cache depth =
is 2 or 32, so making the cache deeper doesn't make much difference.  (Ther=
e is more address-comparison logic, though.) =20

As for the memory usage, it just depends on what BRAM width you need. If yo=
u need a 512-deep by 64-bit wide BRAM, you have to use a Xilinx simple-dual=
 port BRAM with a width of 72, so then you have 8 bits of each location "wa=
sted" which you can use for ILVT flags.  But if you need a 72-bit-wide BRAM=
 for data, then there is no advantage in trying to combine the data and the=
 flags.  In my case I just happened to need 69 and had 3 bits left over.=20

I finished the design that uses the quad-port and I can say it's working we=
ll and it simplified my algorithm significantly.  My clock speed is 360 MHz=
 which was too fast to use a 2x clock to time-slice the BRAMs, but the I-LV=
T design works just fine.
Kevin

Article: 159555
Subject: True Random Number Gen in Virtex 7
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 20 Dec 2016 18:44:08 -0800 (PST)
Links: << >>  << T >>  << A >>
Has anybody tried to build a true random number generator from Catalin Baetoniu's paper?

http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/HighSpeedTrueRandomNumberGeneratorsinXilinxFPGAs.pdf

He uses interconnected ring oscillators in conjunction with a "Linear Hybrid Cellular Automata" for making the distribution more uniform.

I built this in a Virtex 7 to use in the lab for hardware testing.  I had to instantiate the LUTs for the ring oscillator and put DONT_TOUCHes on them.

I just wondered if anyone else had tried this.  It's difficult to tell "how random" the numbers really are without extensive analysis.  I noticed Xilinx has a patent based on this paper, but I didn't know you could patent ring oscillators.

Article: 159556
Subject: Re: True Random Number Gen in Virtex 7
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 24 Dec 2016 14:48:48 -0600
Links: << >>  << T >>  << A >>
On Tue, 20 Dec 2016 18:44:08 -0800, Kevin Neilson wrote:

> Has anybody tried to build a true random number generator from Catalin
> Baetoniu's paper?
> 
> http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/
HighSpeedTrueRandomNumberGeneratorsinXilinxFPGAs.pdf
> 
> He uses interconnected ring oscillators in conjunction with a "Linear
> Hybrid Cellular Automata" for making the distribution more uniform.
> 
> I built this in a Virtex 7 to use in the lab for hardware testing.  I
> had to instantiate the LUTs for the ring oscillator and put DONT_TOUCHes
> on them.
> 
> I just wondered if anyone else had tried this.  It's difficult to tell
> "how random" the numbers really are without extensive analysis.  I
> noticed Xilinx has a patent based on this paper, but I didn't know you
> could patent ring oscillators.

Ring oscillators to generate -- or at least seed -- random numbers isn't 
new.  If there's a patent there, they're probably trying to make a real 
or perceived barrier to people doing it with an Altera part.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 159557
Subject: Re: True Random Number Gen in Virtex 7
From: lasselangwadtchristensen@gmail.com
Date: Mon, 26 Dec 2016 15:44:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Den l=C3=B8rdag den 24. december 2016 kl. 21.48.55 UTC+1 skrev Tim Wescott:
> On Tue, 20 Dec 2016 18:44:08 -0800, Kevin Neilson wrote:
>=20
> > Has anybody tried to build a true random number generator from Catalin
> > Baetoniu's paper?
> >=20
> > http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/
> HighSpeedTrueRandomNumberGeneratorsinXilinxFPGAs.pdf
> >=20
> > He uses interconnected ring oscillators in conjunction with a "Linear
> > Hybrid Cellular Automata" for making the distribution more uniform.
> >=20
> > I built this in a Virtex 7 to use in the lab for hardware testing.  I
> > had to instantiate the LUTs for the ring oscillator and put DONT_TOUCHe=
s
> > on them.
> >=20
> > I just wondered if anyone else had tried this.  It's difficult to tell
> > "how random" the numbers really are without extensive analysis.  I
> > noticed Xilinx has a patent based on this paper, but I didn't know you
> > could patent ring oscillators.
>=20
> Ring oscillators to generate -- or at least seed -- random numbers isn't=
=20
> new.  If there's a patent there, they're probably trying to make a real=
=20
> or perceived barrier to people doing it with an Altera part.

afaict patents have become something big companies have as ammunition again=
st small guys: try to enter the market and will bury you in lawsuits=20
and protection against other big companies: don't sue us will sue you right=
 back and we'll both waste money=20




 =20


Article: 159558
Subject: Re: True Random Number Gen in Virtex 7
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 29 Dec 2016 13:12:02 -0600
Links: << >>  << T >>  << A >>
On Mon, 26 Dec 2016 15:44:02 -0800, lasselangwadtchristensen wrote:

> Den lørdag den 24. december 2016 kl. 21.48.55 UTC+1 skrev Tim Wescott:
>> On Tue, 20 Dec 2016 18:44:08 -0800, Kevin Neilson wrote:
>> 
>> > Has anybody tried to build a true random number generator from
>> > Catalin Baetoniu's paper?
>> > 
>> > http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/
>> HighSpeedTrueRandomNumberGeneratorsinXilinxFPGAs.pdf
>> > 
>> > He uses interconnected ring oscillators in conjunction with a "Linear
>> > Hybrid Cellular Automata" for making the distribution more uniform.
>> > 
>> > I built this in a Virtex 7 to use in the lab for hardware testing.  I
>> > had to instantiate the LUTs for the ring oscillator and put
>> > DONT_TOUCHes on them.
>> > 
>> > I just wondered if anyone else had tried this.  It's difficult to
>> > tell "how random" the numbers really are without extensive analysis. 
>> > I noticed Xilinx has a patent based on this paper, but I didn't know
>> > you could patent ring oscillators.
>> 
>> Ring oscillators to generate -- or at least seed -- random numbers
>> isn't new.  If there's a patent there, they're probably trying to make
>> a real or perceived barrier to people doing it with an Altera part.
> 
> afaict patents have become something big companies have as ammunition
> against small guys: try to enter the market and will bury you in
> lawsuits and protection against other big companies: don't sue us will
> sue you right back and we'll both waste money

Yes, the USPTO has become something of a captive regulator to the big-
money interests.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 159559
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 29 Dec 2016 12:57:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > Will I be able to create a 158 MHz clock on this device?  Or is that
> > beyond its abilities?  Also, I have add and compare circuits that need
> > to run at about 79 MHz.  Will those work properly?
> 
> The /device/ should be capable of up to 300-400MHz - at least that's what
> I've seem in general use.  However it's your problem to make a design that
> will run at the speed you use to run it at.  I wouldn't have thought you
> would have big problems at 79MHz, and might be OK at 158MHz - it really
> depends.
> 
> TimeQuest timing analyser will tell you, among other things, the maximum
> clock speed that each clock domain will run at.  Assuming you have
> constrained your input clocks appropriately (ie have an SDC file that
> indicates their speeds, and any relations between them) then Timequest will
> warn if your design fails to meet your timing constraints.  If you have a
> PLL, it knows the input clock and will calculate the speeds of the generated
> clocks, so in general you just need to tell it the input speeds and it'll
> figure out the rest.
> 
> > I'm moving from the area of digital theory design to FPGA programming
> > reality.  I'm not sure what to expect.
> 
> You might find it useful to have a read through an intro to the tools - for
> instance this my brief rundown aimed at second year university students (in
> the middle of a course doing other things including verilog and
> bare-metal software development):
> 
> http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html

I've been working on designing my L1 cache:

   https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1
   https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png

And I'm about ready to program in a single 128-byte cache row and see
if I can get it working.  I'm going to write it externally and produce
Verilog code using gates and nets.

If I get it to a point where I think it's all there, but it's still
not working, would you be willing to help me debug it?

Best regards,
Rick C. Hodgin

Article: 159560
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 29 Dec 2016 22:26:06 +0000 (GMT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> I've been working on designing my L1 cache:
> 
>    https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1
>    https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png
> 
> And I'm about ready to program in a single 128-byte cache row and see
> if I can get it working.  I'm going to write it externally and produce
> Verilog code using gates and nets.
> 
> If I get it to a point where I think it's all there, but it's still
> not working, would you be willing to help me debug it?

I can't help you debug, since it's your design that only you know on
hardware only you have access to.  Debugging is a very personal penance.

However I suggest you have a look at ModelSim for simulation of your design
- Altera have a free version with some limitations.  For running on hardware
SignalTap gives you visibility of what's going on inside - with the
limitation that the number of signals and time are limited and it typically
involves frequent resynthesis cycles.  Hardware debugging can be slow and it
helps to think carefully about what you want to view before each synthesis
run - simulation has much better visibility shorter round-trip times, so it's
worth starting there unless you really need hardware.

Theo

Article: 159561
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 30 Dec 2016 07:06:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 29, 2016 at 5:26:11 PM UTC-5, Theo Markettos wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > I've been working on designing my L1 cache:
> > 
> >    https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1
> >    https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png
> > 
> > And I'm about ready to program in a single 128-byte cache row and see
> > if I can get it working.  I'm going to write it externally and produce
> > Verilog code using gates and nets.
> > 
> > If I get it to a point where I think it's all there, but it's still
> > not working, would you be willing to help me debug it?
> 
> I can't help you debug, since it's your design that only you know on
> hardware only you have access to.  Debugging is a very personal penance.
> 
> However I suggest you have a look at ModelSim for simulation of your design
> - Altera have a free version with some limitations.  For running on hardware
> SignalTap gives you visibility of what's going on inside - with the
> limitation that the number of signals and time are limited and it typically
> involves frequent resynthesis cycles.  Hardware debugging can be slow and it
> helps to think carefully about what you want to view before each synthesis
> run - simulation has much better visibility shorter round-trip times, so it's
> worth starting there unless you really need hardware.

I appreciate your input, Theo.  Thank you for your help.

I would prefer to do it in simulation.  I have plans to create a tool
to do exactly that.  In fact, I've been building that cache design in
both my mind and GIMP (graphics software).  With my simulation tool,
called Logician, I would be able to create that basic image in a
similar designer which is not just creating the image, but is connecting
the wires together, having gate blocks which appear graphical as in my
image, but contain underlying real logic.

I may go ahead and get that tool done so I can work on those things in
simulation.  If I had that tool completed, I would actually like to
complete my entire CPU and run it in simulation.

Best regards
Rick C. Hodgin

Article: 159562
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 30 Dec 2016 07:42:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 30, 2016 at 10:06:45 AM UTC-5, Rick C. Hodgin wrote:
> On Thursday, December 29, 2016 at 5:26:11 PM UTC-5, Theo Markettos wrote:
> > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > > I've been working on designing my L1 cache:
> > > 
> > >    https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1
> > >    https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png
> > > 
> > > And I'm about ready to program in a single 128-byte cache row and see
> > > if I can get it working.  I'm going to write it externally and produce
> > > Verilog code using gates and nets.
> > > 
> > > If I get it to a point where I think it's all there, but it's still
> > > not working, would you be willing to help me debug it?
> > 
> > I can't help you debug, since it's your design that only you know on
> > hardware only you have access to.  Debugging is a very personal penance.
> > 
> > However I suggest you have a look at ModelSim for simulation of your design
> > - Altera have a free version with some limitations.  For running on hardware
> > SignalTap gives you visibility of what's going on inside - with the
> > limitation that the number of signals and time are limited and it typically
> > involves frequent resynthesis cycles.  Hardware debugging can be slow and it
> > helps to think carefully about what you want to view before each synthesis
> > run - simulation has much better visibility shorter round-trip times, so it's
> > worth starting there unless you really need hardware.
> 
> I appreciate your input, Theo.  Thank you for your help.
> 
> I would prefer to do it in simulation.  I have plans to create a tool
> to do exactly that.  In fact, I've been building that cache design in
> both my mind and GIMP (graphics software).  With my simulation tool,
> called Logician, I would be able to create that basic image in a
> similar designer which is not just creating the image, but is connecting
> the wires together, having gate blocks which appear graphical as in my
> image, but contain underlying real logic.
> 
> I may go ahead and get that tool done so I can work on those things in
> simulation.  If I had that tool completed, I would actually like to
> complete my entire CPU and run it in simulation.

I want my Logician tool to function more or less like this logic sim
tool:

    https://www.kolls.net/gatesim/

    Screenshot:  https://www.kolls.net/gatesim/gatesim_ss.png

It has input, output, and an aggregation ability to create fundamental
circuits which can then be manipulated as larger constructs, as in the
image with the "half adder."

I want to provide noodle connections (as in that image), as well as
square/diagonal-routed lines.  I want to provide a "tactical" view
which shows things in block diagram concept, as well as a "details"
view which shows circuits, and to be able to enable those settings
on individual components within.  I want to be able to drill down
into an aggregation to see the fundamental circuits, and to be able
to leave those settings enabled in future views.

I also want to do it all in OpenGL because I eventually want to
create a process generation feature, which will physically generate
the circuits (in 3D) used for creating transistors on a substrate,
along with all wiring, placement, and routing.  I want it to give
users the ability to take concepts from idea, to design, to testing
and debugging, to physical layout and placement on a semiconductor
substrate.

My goals ultimately are to create a primitive fabrication facility
called Sand Castle Fabs, which uses antiquated process technologies
that are well mature and inexpensive to allow the creation of custom
ICs without the huge cost of modern fabs.  That's a goal I have for
the latter half of the 2020s. :-)

Best regards,
Rick C. Hodgin

Article: 159563
Subject: Slightly OT: Digital watch circuits
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 30 Dec 2016 15:03:30 -0600
Links: << >>  << T >>  << A >>
Someone on reddit asked about quartz watches, and I told them that one 
way to do it would be a counter chain, with the counter outputs feeding 
decimal-to-7-segment decoders.

But, what is actually done?  I could see how one might possibly reduce 
the total transistor count by having a 7-segment clock, with seven or 
fewer flip-flops and various bits of logic to generate the next state and 
the current readout.

I assume that digital watch IC's are some totally custom thing, and I 
wouldn't be surprised if there aren't a bunch of factories out there that 
have lost the recipe and just have the masks.  But -- does anyone know 
what's done?

Thanks.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159564
Subject: Re: Slightly OT: Digital watch circuits
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 30 Dec 2016 16:26:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 30, 2016 at 2:03:38 PM UTC-7, Tim Wescott wrote:
> Someone on reddit asked about quartz watches, and I told them that one=20
> way to do it would be a counter chain, with the counter outputs feeding=
=20
> decimal-to-7-segment decoders.
>=20
> But, what is actually done?  I could see how one might possibly reduce=20
> the total transistor count by having a 7-segment clock, with seven or=20
> fewer flip-flops and various bits of logic to generate the next state and=
=20
> the current readout.
>=20

I seem to remember that the original watch crystals were 32.768kHz, so I as=
sumed that was so they could use a simple 15-FF ripple counter for a divide=
r so as to get the lowest gate count and power.  I assume the rest was, lik=
e you said, 3 or 4 counters (mod-10, mod-6, and mod-12) and some 7-seg deco=
ders.  I can't remember how you set the time on those.  It could have been =
as simple as having a button that would bypass a few stages of the ripple c=
ounter so you could speed up the clock until you got to the right time.

Article: 159565
Subject: Re: Slightly OT: Digital watch circuits
From: rickman <gnuarm@gmail.com>
Date: Sat, 31 Dec 2016 02:54:41 -0500
Links: << >>  << T >>  << A >>
On 12/30/2016 4:03 PM, Tim Wescott wrote:
> Someone on reddit asked about quartz watches, and I told them that one
> way to do it would be a counter chain, with the counter outputs feeding
> decimal-to-7-segment decoders.
>
> But, what is actually done?  I could see how one might possibly reduce
> the total transistor count by having a 7-segment clock, with seven or
> fewer flip-flops and various bits of logic to generate the next state and
> the current readout.
>
> I assume that digital watch IC's are some totally custom thing, and I
> wouldn't be surprised if there aren't a bunch of factories out there that
> have lost the recipe and just have the masks.  But -- does anyone know
> what's done?

I'm not sure what you are confused about.  I also don't understand your 
idea of somehow using just 7 FFs to manage a clock display.

The original digital clocks did use a counter chain which generated 
either a 1 pps signal to drive the time counters if keeping seconds or a 
1 pp minute signal to drive the time counter if not keeping seconds.

Today there is little reason to minimize transistor counts.  Transistors 
are nearly free even if you make a million dies.  They use a 4 bit CPU 
to do all the work which likely includes dividing the 32.768 kHz clock 
to 1 second.

You can check the Epson web site for CPU chips which I believe are the 
type of 4 bit CPUs they use in watches.

Remember that watches often do a lot more than just tell time these days.

-- 

Rick C

Article: 159566
Subject: Re: Slightly OT: Digital watch circuits
From: Jean-marc Lienher <jean-marc.lienher@bluewin.ch>
Date: Sat, 31 Dec 2016 14:42:54 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> You can check the Epson web site for CPU chips which I believe are the
> type of 4 bit CPUs they use in watches.

Epson or if you want the Swiss touch you can check the Swatch group web 
site:
http://www.emmicroelectronic.com/products/microcontrollers/lcd-driver/em6627




Article: 159567
Subject: Re: Slightly OT: Digital watch circuits
From: rickman <gnuarm@gmail.com>
Date: Sat, 31 Dec 2016 12:14:53 -0500
Links: << >>  << T >>  << A >>
On 12/31/2016 8:42 AM, Jean-marc Lienher wrote:
> rickman wrote:
>> You can check the Epson web site for CPU chips which I believe are the
>> type of 4 bit CPUs they use in watches.
>
> Epson or if you want the Swiss touch you can check the Swatch group web
> site:
> http://www.emmicroelectronic.com/products/microcontrollers/lcd-driver/em6627

Thank you.  I have seen these as well, but couldn't remember the 
company.  I think I have seen plans for a radio controlled clock using a 
demodulator chip and an EMmicro CPU.  Great power consumption.

-- 

Rick C

Article: 159568
Subject: Re: Slightly OT: Digital watch circuits
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 31 Dec 2016 12:32:12 -0600
Links: << >>  << T >>  << A >>
On Sat, 31 Dec 2016 02:54:41 -0500, rickman wrote:

> On 12/30/2016 4:03 PM, Tim Wescott wrote:
>> Someone on reddit asked about quartz watches, and I told them that one
>> way to do it would be a counter chain, with the counter outputs feeding
>> decimal-to-7-segment decoders.
>>
>> But, what is actually done?  I could see how one might possibly reduce
>> the total transistor count by having a 7-segment clock, with seven or
>> fewer flip-flops and various bits of logic to generate the next state
>> and the current readout.
>>
>> I assume that digital watch IC's are some totally custom thing, and I
>> wouldn't be surprised if there aren't a bunch of factories out there
>> that have lost the recipe and just have the masks.  But -- does anyone
>> know what's done?
> 
> I'm not sure what you are confused about.  I also don't understand your
> idea of somehow using just 7 FFs to manage a clock display.
> 
> The original digital clocks did use a counter chain which generated
> either a 1 pps signal to drive the time counters if keeping seconds or a
> 1 pp minute signal to drive the time counter if not keeping seconds.
> 
> Today there is little reason to minimize transistor counts.  Transistors
> are nearly free even if you make a million dies.  They use a 4 bit CPU
> to do all the work which likely includes dividing the 32.768 kHz clock
> to 1 second.
> 
> You can check the Epson web site for CPU chips which I believe are the
> type of 4 bit CPUs they use in watches.
> 
> Remember that watches often do a lot more than just tell time these
> days.

Seven FF _per digit_.  I'm more interested in what was done back in the 
day.  Do you know how long the 4-bit CPU has been used?

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 159569
Subject: Re: Slightly OT: Digital watch circuits
From: rickman <gnuarm@gmail.com>
Date: Sat, 31 Dec 2016 14:08:01 -0500
Links: << >>  << T >>  << A >>
On 12/31/2016 1:32 PM, Tim Wescott wrote:
> On Sat, 31 Dec 2016 02:54:41 -0500, rickman wrote:
>
>> On 12/30/2016 4:03 PM, Tim Wescott wrote:
>>> Someone on reddit asked about quartz watches, and I told them that one
>>> way to do it would be a counter chain, with the counter outputs feeding
>>> decimal-to-7-segment decoders.
>>>
>>> But, what is actually done?  I could see how one might possibly reduce
>>> the total transistor count by having a 7-segment clock, with seven or
>>> fewer flip-flops and various bits of logic to generate the next state
>>> and the current readout.
>>>
>>> I assume that digital watch IC's are some totally custom thing, and I
>>> wouldn't be surprised if there aren't a bunch of factories out there
>>> that have lost the recipe and just have the masks.  But -- does anyone
>>> know what's done?
>>
>> I'm not sure what you are confused about.  I also don't understand your
>> idea of somehow using just 7 FFs to manage a clock display.
>>
>> The original digital clocks did use a counter chain which generated
>> either a 1 pps signal to drive the time counters if keeping seconds or a
>> 1 pp minute signal to drive the time counter if not keeping seconds.
>>
>> Today there is little reason to minimize transistor counts.  Transistors
>> are nearly free even if you make a million dies.  They use a 4 bit CPU
>> to do all the work which likely includes dividing the 32.768 kHz clock
>> to 1 second.
>>
>> You can check the Epson web site for CPU chips which I believe are the
>> type of 4 bit CPUs they use in watches.
>>
>> Remember that watches often do a lot more than just tell time these
>> days.
>
> Seven FF _per digit_.  I'm more interested in what was done back in the
> day.  Do you know how long the 4-bit CPU has been used?

I don't think 7 FFs per digit was ever used... but then I never reverse 
engineered a watch.  I believe every clock chip data sheet I've ever 
seen showed a direct binary counter to generate the 1 pps or 1 ppm 
clock.  Then the time was kept by a chain of 4 bit decimal counters some 
of which only go up to 6 or 2 depending on the position.  The digits 
were then driven by BCD to 7 segment decoders.  But I can't say for sure 
that is how they designed custom watch chips.  I think you would have to 
ask the designer to be certain.

I don't know for sure how long 4 bit MCUs have been used for watches, 
but you can look back to see when they started making watches with the 
date and other more complex functions.  A 4 bit MCU is not very complex 
and it wouldn't require much in the way of functionality to make a CPU 
the right choice over discrete logic.  Leap year at century and 
millennial boundaries would be a bit much for discrete counters.

It seems to be hard to find any info with Google.  There are so many 
Linux based watches these days that none of the old stuff shows up.

-- 

Rick C

Article: 159570
Subject: Re: Slightly OT: Digital watch circuits
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 31 Dec 2016 23:49:06 -0600
Links: << >>  << T >>  << A >>
On Sat, 31 Dec 2016 14:08:01 -0500, rickman wrote:

> On 12/31/2016 1:32 PM, Tim Wescott wrote:
>> On Sat, 31 Dec 2016 02:54:41 -0500, rickman wrote:
>>
>>> On 12/30/2016 4:03 PM, Tim Wescott wrote:
>>>> Someone on reddit asked about quartz watches, and I told them that
>>>> one way to do it would be a counter chain, with the counter outputs
>>>> feeding decimal-to-7-segment decoders.
>>>>
>>>> But, what is actually done?  I could see how one might possibly
>>>> reduce the total transistor count by having a 7-segment clock, with
>>>> seven or fewer flip-flops and various bits of logic to generate the
>>>> next state and the current readout.
>>>>
>>>> I assume that digital watch IC's are some totally custom thing, and I
>>>> wouldn't be surprised if there aren't a bunch of factories out there
>>>> that have lost the recipe and just have the masks.  But -- does
>>>> anyone know what's done?
>>>
>>> I'm not sure what you are confused about.  I also don't understand
>>> your idea of somehow using just 7 FFs to manage a clock display.
>>>
>>> The original digital clocks did use a counter chain which generated
>>> either a 1 pps signal to drive the time counters if keeping seconds or
>>> a 1 pp minute signal to drive the time counter if not keeping seconds.
>>>
>>> Today there is little reason to minimize transistor counts. 
>>> Transistors are nearly free even if you make a million dies.  They use
>>> a 4 bit CPU to do all the work which likely includes dividing the
>>> 32.768 kHz clock to 1 second.
>>>
>>> You can check the Epson web site for CPU chips which I believe are the
>>> type of 4 bit CPUs they use in watches.
>>>
>>> Remember that watches often do a lot more than just tell time these
>>> days.
>>
>> Seven FF _per digit_.  I'm more interested in what was done back in the
>> day.  Do you know how long the 4-bit CPU has been used?
> 
> I don't think 7 FFs per digit was ever used... but then I never reverse
> engineered a watch.  I believe every clock chip data sheet I've ever
> seen showed a direct binary counter to generate the 1 pps or 1 ppm
> clock.  Then the time was kept by a chain of 4 bit decimal counters some
> of which only go up to 6 or 2 depending on the position.  The digits
> were then driven by BCD to 7 segment decoders.  But I can't say for sure
> that is how they designed custom watch chips.  I think you would have to
> ask the designer to be certain.
> 
> I don't know for sure how long 4 bit MCUs have been used for watches,
> but you can look back to see when they started making watches with the
> date and other more complex functions.  A 4 bit MCU is not very complex
> and it wouldn't require much in the way of functionality to make a CPU
> the right choice over discrete logic.  Leap year at century and
> millennial boundaries would be a bit much for discrete counters.
> 
> It seems to be hard to find any info with Google.  There are so many
> Linux based watches these days that none of the old stuff shows up.

Linux watches.  Jeeze.  When I was a kid, watches had springs and wheels 
and little things that went "ziiiiing!" when you tried to take them apart 
(I think they were called escapements, maybe because of their habits).

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 159571
Subject: Re: Slightly OT: Digital watch circuits
From: rickman <gnuarm@gmail.com>
Date: Sun, 1 Jan 2017 16:44:58 -0500
Links: << >>  << T >>  << A >>
On 1/1/2017 12:49 AM, Tim Wescott wrote:
> On Sat, 31 Dec 2016 14:08:01 -0500, rickman wrote:
>
>> On 12/31/2016 1:32 PM, Tim Wescott wrote:
>>> On Sat, 31 Dec 2016 02:54:41 -0500, rickman wrote:
>>>
>>>> On 12/30/2016 4:03 PM, Tim Wescott wrote:
>>>>> Someone on reddit asked about quartz watches, and I told them that
>>>>> one way to do it would be a counter chain, with the counter outputs
>>>>> feeding decimal-to-7-segment decoders.
>>>>>
>>>>> But, what is actually done?  I could see how one might possibly
>>>>> reduce the total transistor count by having a 7-segment clock, with
>>>>> seven or fewer flip-flops and various bits of logic to generate the
>>>>> next state and the current readout.
>>>>>
>>>>> I assume that digital watch IC's are some totally custom thing, and I
>>>>> wouldn't be surprised if there aren't a bunch of factories out there
>>>>> that have lost the recipe and just have the masks.  But -- does
>>>>> anyone know what's done?
>>>>
>>>> I'm not sure what you are confused about.  I also don't understand
>>>> your idea of somehow using just 7 FFs to manage a clock display.
>>>>
>>>> The original digital clocks did use a counter chain which generated
>>>> either a 1 pps signal to drive the time counters if keeping seconds or
>>>> a 1 pp minute signal to drive the time counter if not keeping seconds.
>>>>
>>>> Today there is little reason to minimize transistor counts.
>>>> Transistors are nearly free even if you make a million dies.  They use
>>>> a 4 bit CPU to do all the work which likely includes dividing the
>>>> 32.768 kHz clock to 1 second.
>>>>
>>>> You can check the Epson web site for CPU chips which I believe are the
>>>> type of 4 bit CPUs they use in watches.
>>>>
>>>> Remember that watches often do a lot more than just tell time these
>>>> days.
>>>
>>> Seven FF _per digit_.  I'm more interested in what was done back in the
>>> day.  Do you know how long the 4-bit CPU has been used?
>>
>> I don't think 7 FFs per digit was ever used... but then I never reverse
>> engineered a watch.  I believe every clock chip data sheet I've ever
>> seen showed a direct binary counter to generate the 1 pps or 1 ppm
>> clock.  Then the time was kept by a chain of 4 bit decimal counters some
>> of which only go up to 6 or 2 depending on the position.  The digits
>> were then driven by BCD to 7 segment decoders.  But I can't say for sure
>> that is how they designed custom watch chips.  I think you would have to
>> ask the designer to be certain.
>>
>> I don't know for sure how long 4 bit MCUs have been used for watches,
>> but you can look back to see when they started making watches with the
>> date and other more complex functions.  A 4 bit MCU is not very complex
>> and it wouldn't require much in the way of functionality to make a CPU
>> the right choice over discrete logic.  Leap year at century and
>> millennial boundaries would be a bit much for discrete counters.
>>
>> It seems to be hard to find any info with Google.  There are so many
>> Linux based watches these days that none of the old stuff shows up.
>
> Linux watches.  Jeeze.  When I was a kid, watches had springs and wheels
> and little things that went "ziiiiing!" when you tried to take them apart
> (I think they were called escapements, maybe because of their habits).

Yeah, I'm sure phones where those things you could club a person to 
death with too rather than a popular way of watching your favorite TV 
show.  Back then the picture phone was something you saw at a World's Fair.

-- 

Rick C

Article: 159572
Subject: Re: Slightly OT: Digital watch circuits
From: Anssi Saari <as@sci.fi>
Date: Mon, 02 Jan 2017 12:09:01 +0200
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> I don't know for sure how long 4 bit MCUs have been used for watches,
> but you can look back to see when they started making watches with the
> date and other more complex functions.  A 4 bit MCU is not very
> complex and it wouldn't require much in the way of functionality to
> make a CPU the right choice over discrete logic.  Leap year at century
> and millennial boundaries would be a bit much for discrete counters.

I vaguely remember getting a digital wristwatch in the late 70s,
Japanese Citizen I think. I'm pretty sure it had two times (i.e. other
timezone for travel and such, no idea if it was just whole hour
offsets), calendar, stopwatch with 1/100th second accuracy. Nothing more
than that, no alarm or timer that were pretty common early
on. Unfortunately I can't remember if the calendar could handle leap
years or not. BTW, that seems to be a common thing to skip with today's
analog wristwatches too, at least with the cheaper ones.

Article: 159573
Subject: Re: Slightly OT: Digital watch circuits
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 02 Jan 2017 14:35:36 +0000 (GMT)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:
> Seven FF _per digit_.  I'm more interested in what was done back in the 
> day.  Do you know how long the 4-bit CPU has been used?

The advert for one of the first (Sinclair Black Watch, 1975) describes the
chip:

<quote>
The chip...
The heart of the Black Watch is a unique IC designed by Sinclair and Custom
-built for them using state -of- the -art technology - integrated injection
logic. This chip of silicon measures only 3 mm x 3 mm and contains over
2000 transistors.The circuit includes
a) reference oscillator 
b) divider chain
c) decoder circuits 
d) display inhibit circuits 
e) display driving circuits.
The chip is totally designed and manufactured in the UK, and is
the first design to incorporate all circuitry for a digital watch on a
single chip.

...and how it works 
A crystal -controlled reference is used to
drive a chain of 15 binary dividers which reduce the frequency from 32,768
Hz to 1 Hz.This accurate signal is then counted into units of seconds,
minutes, and hours, and on request the stored information is processed by
the decoders and display drivers to feed the four 7- segment LED displays.
When the display is not in operation, special power- saving circuits on the
chip reduce current consumption to only a few microamps.
</quote>

http://www.americanradiohistory.com/Archive-Practical/Wireless/70s/PW-1976-03.pdf
page 68
(fab was supposed to be Mullard but they pulled out, I think it was
eventually ITT)

Theo

Article: 159574
Subject: Re: Slightly OT: Digital watch circuits
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Mon, 2 Jan 2017 08:07:39 -0700
Links: << >>  << T >>  << A >>
On 12/30/2016 02:03 PM, Tim Wescott wrote:
> Someone on reddit asked about quartz watches, and I told them that one
> way to do it would be a counter chain, with the counter outputs feeding
> decimal-to-7-segment decoders.
>
> But, what is actually done?  I could see how one might possibly reduce
> the total transistor count by having a 7-segment clock, with seven or
> fewer flip-flops and various bits of logic to generate the next state and
> the current readout.
>
> I assume that digital watch IC's are some totally custom thing, and I
> wouldn't be surprised if there aren't a bunch of factories out there that
> have lost the recipe and just have the masks.  But -- does anyone know
> what's done?
>
> Thanks.
>
Looking at a copy of the National Semiconductor 1977 MOS LSI data book, 
they have several watch IC's shown. From the block diagrams, it looks 
like they are using dividers off the crystal oscillator down to 4KHz and 
1Hz, followed by "Display and Set Control Logic". There are individual 
signals down to the hours, minutes and seconds counters. The counter 
outputs go down to "Select Counter Logic" which feeds a "7 segment 
decoder" block.
The block diagrams for the MM5829, MM5860/MM58601, and MM5885 chips are 
all fairly similar, in that they show separate counters for hours, 
minutes and seconds.
The MM5890 "LCD Chronograph" chip has a stop watch built in and it shows 
separate counters for the stop watch timing, feeding into the counter 
select logic block.

It would be possible to implement a state machine that counts in 7 
segment format, but it would be ugly to do, and probably larger than 
simple ripple counters feeding into a shared bcd to 7 segment decoder.

Happy New Year,
BobH



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