Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 159551Cecil 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. JonArticle: 159552
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
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> 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. KevinArticle: 159555
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
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.comArticle: 159557
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 =20Article: 159558
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.comArticle: 159559
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. HodginArticle: 159560
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. TheoArticle: 159561
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. HodginArticle: 159562
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: 159563Someone 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
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
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 CArticle: 159566
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/em6627Article: 159567
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 CArticle: 159568
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.comArticle: 159569
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 CArticle: 159570
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.comArticle: 159571
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 CArticle: 159572
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
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) TheoArticle: 159574
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:
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