<cyrozap>
I got UDB->Verilog finished for the PSoC 5LP :)
<balrog>
cyrozap: nice!!!
<balrog>
so that leaves routing?
<cyrozap>
Yup
<balrog>
how "bad" is routing?
<cyrozap>
From what pointfree has discovered so far, not too bad
<cyrozap>
The real complexity will come from all the configuration options that I'm currently ignoring.
<balrog>
for the UDBs?
<balrog>
start with the basics ;)
<pie__>
anyone familiar with cleanroom environments?
<pointfree>
cyrozap: Cool! :)
<cyrozap>
balrog: For instance, the UDB->Verilog code assumes clk and reset signals are active high, but you can actually invert them for selected UDBs
<balrog>
that's... interesting.
<balrog>
why would you do that? to be able to pack more logic in?
<cyrozap>
It's just adding NOT gates
<cyrozap>
Well, configurable NOT gates
<balrog>
yes... for more versatility?
<cyrozap>
And then of course you can turn clocks on and off, route them differently, trigger them from firmware (i.e., other registers), etc.
<cyrozap>
And the Datapath element is incredibly configurable, and is probably more valuable than the PLDs alone.
<pointfree>
cyrozap: So you figured out registered logic for the PLD's? I have only done combinational logic so far and some routing. I don't know anything about the Datapath.
<cyrozap>
pointfree: Yup, the code outputs an entire Verilog module for the whole UDB (sans-Datapath), including Macrocell config (so clocked logic, XOR feedback, carry between MC's, etc.)
<cyrozap>
Its output is really verbose since it just does a lot of string building, but I think we can use Yosys to do any simplification we want.
<pointfree>
cyrozap: So this is embedded in a preconfigured route I presume?
<cyrozap>
pointfree: I'm not sure what you mean by that
<pointfree>
cyrozap: I've replaced understood pieces of synthesized logic etc, such as an XOR gate with an XNOR gate while leaving the same routing configuration intact and then loading it with openocd. I was asking if you were doing something similar.
<cyrozap>
pointfree: Oh, I haven't done any physical RE yet, this is all based on the public docs
<cyrozap>
To be clear, it literally can only parse the 64-byte UDB config memory right now
<azonenberg_hk>
So this is interesting... wonder if it's reproducible
<azonenberg_hk>
had a win10 virtualbox VM
<azonenberg_hk>
cortana was bugging me about using it
<azonenberg_hk>
so i searched "cortana" in control panel settings to figure out how to shut it up
<rqou>
I got a host hard crash the other day with qemu/kvm
<rqou>
that's scary
flaviusb has quit [Quit: Leaving.]
MikeFair has joined ##openfpga
<MikeFair>
Hi all!
<cr1901_modern>
cyrozap: Did you ever figure out how to program the mimasv2 from migen? It appears to requires some sort of ".msc" file, unlike every Xilinx board I've seen up to this point.
<cr1901_modern>
And from googling, .mcs is like Intel HEX, but not
<MikeFair>
I was curious about experimenting with FPGAs and CPLDs and was wondering if there were an software emulators out there to start experimenting with; specifically anything that's more easy to use so I see what's going on with the logic I write
<cyrozap>
cr1901_modern: I just use my J-Link and OpenOCD
<cr1901_modern>
I don't have a J-Link :(
<cyrozap>
cr1901_modern: Or you can use the Python-based tool from Numato to flash over USB
<cyrozap>
cr1901_modern: You can connect with any JTAG adapter
<cr1901_modern>
Well yes, I have a glorified FT232H breakout board for that purpose
<cr1901_modern>
At which point I could use a flash bitstream proxy
<rqou>
Mimas V2? The custom Python thing just accepts a bin file
<cyrozap>
cr1901_modern: Yeah, OpenOCD has a jtagspi driver now, which you can use with some migen-generated proxy bitstreams
<cr1901_modern>
rqou: You are correct, I misread
<cr1901_modern>
Doesn't look like the PIC firmware is open source tho. Kinda curious about dumping it (even though I have no idea where to start)
<cyrozap>
MikeFair: Well, there are a bunch of freely-available VHDL and Verilog simulators you can run locally (like iverilog), since most people simulate their designs a lot before even touching real hardware. There's also https://www.edaplayground.com/ if you want to try something online.
<MikeFair>
Anything that has a library of IP blocks to pull from?
<MikeFair>
or tutorials/walkthroughs
<MikeFair>
(I guess I could hunt around the web) -- edaplayground looks interesting
<MikeFair>
Ouch, I didn't realize there'd be so many "flavors" of Verilog
<cyrozap>
MikeFair: Do you have any digital logic experience already? Also you might want to ask in ##fpga as well, since this channel is primarily for open source FPGA stuff (though a lot of off-topic conversations happen here anyways...).
<MikeFair>
cyrozap: None yet; other than what I've absorbed through copious amounts of online reading about them; I started on ##fpga and was told about this channel since I'm primarily an open source/free software guy myself :)
<cyrozap>
MikeFair: Oh, cool :)
<azonenberg_hk>
MikeFair: For small / low gate count designs
<azonenberg_hk>
You might find it instructive to write verilog and then run it through the greenpak toolchain
<azonenberg_hk>
you can import the generated bitstream into a schematic using the silego ide
<azonenberg_hk>
Which will let you see how your logic actually got synthesized
<cyrozap>
MikeFair: As for variations of Verilog, there's only a few versions of Verilog (which is most widely supported by FOSS tools) and SystemVerilog (which has lots of proprietary tool support, but not much FOSS support yet)
<MikeFair>
I'm liking the look of edaplayground.com for something just to step through the compile/execute/debug cycle
<azonenberg_hk>
xilinx has a similar capability in their tools but the toolchain is massive (tens of GB) and the schematic viewer is not all that great
<MikeFair>
cyrozap: I was just getting overwhlemed by the edaplayground drop downs
<MikeFair>
because I don't have any background for distinguishing "which is the one for me"
<azonenberg_hk>
Plain verilog-2001 or -2008 is probably the way to go for wide toolchain support, both free and commercial
<azonenberg_hk>
or comparable-age VHDL specs
<azonenberg_hk>
although right now the f/oss world has better verilog support
<MikeFair>
(but I figure it's like any other programming language with lots of "variants" -- fidn the one that works with the toolchain I've got; learn more as you go)
<azonenberg_hk>
because yosys is currently verilog-only
<azonenberg_hk>
As i mentioned previously there have been several attempts to make vhdl front-ends, and one is on the wishlist
<azonenberg_hk>
but none are in a usable state as of now
<MikeFair>
yes, focusing on the F/OSS toolchain support; even focusing on exclusively F/OSS is good for me
<azonenberg_hk>
So if you want free compiler support, i'd stick with verilog
<azonenberg_hk>
In that case your options for devices are lattice ice40 on the larger end and silego greenpak4 on the low end
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg_hk>
ice40 is small as fpgas go in general, but the ice40 8k is the largest part with a f/oss toolchain that i am aware of
<MikeFair>
I saw a talk on PSHDL (http://pshdl.org) and that really caught my attention
<azonenberg_hk>
there's several projects working on higher level languages for fpgas, like migen (python to vhdl)
* lain
.oO(april fools joke: release a postscript-based hdl)
<azonenberg_hk>
i havent used any of them extensively
<azonenberg_hk>
lain: loool
<azonenberg_hk>
Not TeX based?
<azonenberg_hk>
LaTeX verilog back end :p
<lain>
haha
<lain>
oh oh
<lain>
bonus points: you send it to the printer, and it's written such that the postscript runs in the printer and generates verilog output, which is then printed
<lain>
printer as hdl compiler
<lain>
revolutionary!
<azonenberg_hk>
lain: lool
<lain>
:D
<azonenberg_hk>
MikeFair: The other project going on here is me and whitequark trying to develop a HDL for PCB design
<cr1901_modern>
ice40 8k I've heard described as a "Spartan 6 LX5" if such a thing existed.
<azonenberg_hk>
rather than drawing schematics
<MikeFair>
lain: Actually, it prints the IC mask implementing your chip ;)
<cr1901_modern>
Which is a respectable size for plenty of projects
<azonenberg_hk>
cr1901_modern: that sounds on par with the gate count, but the s6 has more peripherals
<azonenberg_hk>
cr1901_modern: well considering my next design will use an artix7 100t...
<lain>
MikeFair: hahahaha oh man that'd be great
<cr1901_modern>
azonenberg_hk: You don't count! And I pray I don't succumb to your mentality :P
<MikeFair>
My crazy "revolutionary idea" is to make hardware using minecraft
<cr1901_modern>
I want someone to slap me if I ever decide I need an artix7 100t for anything *I* personally want to do
<MikeFair>
not that it's that "crazy" or "revolutionary"
laintoo_ has joined ##openfpga
<azonenberg_hk>
MikeFair: there was serious discussion here of making a minecraft P&R and yosys redstone cell library
<azonenberg_hk>
and submitting a pull request on april 1st
laintoo has quit [Ping timeout: 250 seconds]
laintoo_ is now known as laintoo
<cr1901_modern>
Who is USB vendor 2A19?
<MikeFair>
azonenberg: I've used/compiled/ran minetest the most complete/open of the F/OSS minecraft implemnetations I saw
<azonenberg_hk>
cr1901_modern: So listen to the specs for the project i have in mind
<azonenberg_hk>
and tell me how you'd run it on something smaller :p
<cyrozap>
lain: Isn't PS Turing-complete? You could run the whole toolchain on the printer ;)
<azonenberg_hk>
cyrozap: that was the point
<lain>
cyrozap: exactly :D
<azonenberg_hk>
you write your design in postscript
<azonenberg_hk>
then the printer prints mask layout
<azonenberg_hk>
cr1901_modern: Four 8-pin I/O banks
<cr1901_modern>
A CPLD can do that, but continue ;)
<azonenberg_hk>
Each bank has an internal programmable power supply that can go up to 5V, a power-output pin for driving external devices
<lain>
cr1901_modern: I can't find 2a19 in any public databases
<azonenberg_hk>
and a power-input pin for using a reference voltage from an external device
<lain>
but then, I also can't see my vendor ID anywhere
<azonenberg_hk>
There's also a DAC for setting an input threshold and a comparator for each pin
<lain>
so these aren't comprehensive
<azonenberg_hk>
so you can set Vih at an arbitrary level
<azonenberg_hk>
then an output driver
<azonenberg_hk>
Programmable pullups/downs
<cr1901_modern>
Okay, so I'm lost already... an artix isn't going to accept 5V
<azonenberg_hk>
yes thats what the comparators are for
<azonenberg_hk>
feed Vin to the comparator, check it against Vih from the DAC
<azonenberg_hk>
then output a 3.3V or lower signal to the artix
<azonenberg_hk>
So you have one DAC per IO bank and one comparator per input pin
<azonenberg_hk>
The idea is to provide I/O at up to 150-200 Mbps speeds with levels anywhere from ~1.5 to 5V, runtime adjustable
<azonenberg_hk>
in say 50 mV increments
<azonenberg_hk>
split into four banks each capable of running at their own level
<cr1901_modern>
A Spartan 6 can't do this because?
<azonenberg_hk>
make sense so far? No FPGA yet, just peripherals
<cr1901_modern>
Also, I really don't understand your circuitry, but I'll ask you to elaborate at another time :P.
<azonenberg_hk>
So then you attach a gigabit ethernet PHY and 2-4 GB of DDR3 800 with a 32-bit wide data bus
scrts has quit [Ping timeout: 256 seconds]
<azonenberg_hk>
Inside the FPGA, you have a series of digital IP cores and a crossbar switch so that you can hook them up arbitrarily
<cr1901_modern>
Okay, *that* part a Spartan6 can't do
<azonenberg_hk>
plus a TCP offload engine to talk to the ethernet
<azonenberg_hk>
So for example, you'll have say eight JTAG masters, eight channels of I2C, eight of SPI, eight UARTs, a 32-bit GPIO bitbang interface, a 32-channel logic analyzer
<cr1901_modern>
But that is that really for lack of space? Just the fact that S6's transceivers kinda fizzle out at high-end stuff?
<azonenberg_hk>
then muxes so you can assign any pin of those peripherals to any of the 32 GPIOs (except for the LA and GPIO port, which are always connected to every pin and you can just ignore ones you're not using)
<azonenberg_hk>
last i checked spartan6 had trouble with DDR3 at higher speeds
<cr1901_modern>
So you basically want a swiss-army chainsaw of GPIO
<azonenberg_hk>
I call it STARSHIP RAIDER
<azonenberg_hk>
It's the futuristic bus pirate
<cr1901_modern>
Of ffs... XD
<cr1901_modern>
Space Raider Ideon
<azonenberg_hk>
I want to be able to hook up a bunch of pins to test points on a random board I'm REing
<azonenberg_hk>
Use a low-speed ADC to figure out what voltage level everything runs at
<azonenberg_hk>
then without touching any physical setup
<azonenberg_hk>
run the LA to see what kind of traffic is going back and forth
<azonenberg_hk>
when i find an i2c bus, hook up an i2c master and probe it
<azonenberg_hk>
when i find a uart, decode it and hook it up to a telnet socket
<azonenberg_hk>
Rather than lugging around a rom dumper, a saleae, a usb-uart, a bunch of jtag dongles, etc
<cr1901_modern>
Okay, I can appreciate that you'll need a lot of routing resources for the crossbar, but >>
<azonenberg_hk>
each with their own set of supported io voltages and needing a separate usb port
<azonenberg_hk>
I want something that can do all of it at once
<cr1901_modern>
1. This still sounds doable with a s6 aside from the transceiver speed
<azonenberg_hk>
Gig-e is doable on a spartan6
<azonenberg_hk>
But among other things, i dont need a huge number of io pins
<cr1901_modern>
2. I imagine there are optimizations to make a crossbar fit on s6.
<azonenberg_hk>
a 100k cell spartan6 is a) not supported by vivado, b) not supported by a free compiler at all, and c) not available in a 256-pin package
<azonenberg_hk>
you need 484+
<lain>
the only reason I avoid s6 these days is xst doesn't support vhdl-2008
<azonenberg_hk>
the 100k cell artix7 is supported by the free builds of both ise and vivado
<azonenberg_hk>
so you have your choice of tools
<cr1901_modern>
interesting...
<azonenberg_hk>
and comes in a 256-pin 4-layer-pcb compatible package
<cr1901_modern>
azonenberg_hk: The reason I harp on s6 vs artix is because the smallest artix is quite larger than even a moderate size s6
<azonenberg_hk>
what do you define as moderate size?
<cr1901_modern>
lx45
<azonenberg_hk>
b/c artix has parts down to i think 12k or 15k cells
<azonenberg_hk>
I just want something bigger
<lain>
( ͡° ͜ʖ ͡°)
<cr1901_modern>
lx25 or lx45 is moderate to me
<azonenberg_hk>
cost is another reason
<azonenberg_hk>
xc6slx100-2fgg484c
<azonenberg_hk>
$124.04 on digikey, MOQ 60 units, non-stock
<azonenberg_hk>
xc7a100t-1ftg256c
<lain>
when will s7 be real
<azonenberg_hk>
$109.20 on digikey, available in single units
<azonenberg_hk>
390 in stock
<cr1901_modern>
And I did a rough calculation; the biggest artix7 is 10 times as large as an lx45, which is reasonably the biggest FPGA I can afford
<cr1901_modern>
or the biggest free* artix
<cr1901_modern>
I prefer minimalism/not paying for things I'm unlikely to use :)
<cyrozap>
azonenberg_hk: That sounds like a perfect application for a PSoC 5LP, minus a few features.
<azonenberg_hk>
Oh and, here's another bit
<azonenberg_hk>
i'm speccing a 100t because i dont know how many gates i need, and i want to leave room for the end user of the system to load their own additional logic into it
* cr1901_modern
does that just fine with a Lattice 1k ;)
<cr1901_modern>
I jest, but I'm leaving room for some user logic on my design
<cyrozap>
No DDR, no Ethernet (so you'd have to use USB), but LA could be passed through to the host and you could dynamically reconfigure any peripherals you need.
<MikeFair>
azonenberg: I'm obviously not an expert, but what about putting the different IP block configurations in the Flash RAM of something like an MCU; then just have a single/small FPGA capable of detecting what it finds; it tells the MCU, then MCU then programs the other parts of the FGPA
<cr1901_modern>
FPGAs nowadays support live partial reconfiguration, though I have no idea how it works
<azonenberg_hk>
cyrozap: can you get a 32-channel LA with 200+ MHz I/O speeds streaming to gigabit ethernet in a psoc?
<azonenberg_hk>
Don't think so
<azonenberg_hk>
cr1901_modern: With FTG256 footprint in artix7 i get scaling from
azonenberg_hk has quit [Quit: Leaving.]
azonenberg_hk1 has joined ##openfpga
azonenberg_hk1 is now known as azonenberg_hk
<cr1901_modern>
get scaling from Quit Leaving?
<cr1901_modern>
that's an interesting amount of scaling
<azonenberg_hk>
Back, wifi dropped out
<azonenberg_hk>
(14:02:36) azonenberg_hk: cyrozap: can you get a 32-channel LA with 200+ MHz I/O speeds streaming to gigabit ethernet in a psoc?
<azonenberg_hk>
(14:02:37) azonenberg_hk: Don't think so
<azonenberg_hk>
cr1901_modern: With FTG256 footprint i get scaling from 15k to 100k logiccells
<azonenberg_hk>
i can load the board with anything in that range (only the 100 supported by ise, rest need vivado but the free version works)
<azonenberg_hk>
xc7a15t is down to $25.69
<MikeFair>
azonenberg: That way you don't have to put it all onto one chip; you only require enough space for the one you'll actually need
<cyrozap>
azonenberg_hk: As I said, minus a few features. A PSoC-based device would be more of a "Bus Pirate Plus".
<MikeFair>
azonenberg: I'm obviously not an expert, but what about putting the different IP block configurations in the Flash RAM of something like an MCU; then just have a single/small FPGA capable of detecting what it finds; it tells the MCU, then MCU then programs the other parts of the FGPA
<azonenberg_hk>
The 35t is $34 which is a massive capacity increase for a tiny cost increase
<cr1901_modern>
azonenberg_hk: That's fair. But again, even an artix15 is kinda overkill for a lot of things I want to do
<azonenberg_hk>
cyrozap: Yeah
<MikeFair>
cyrozap: Yeah, I think we're both seeing the same kind of thing
<azonenberg_hk>
The whole point here is to be a major speed boost
<azonenberg_hk>
i need something able to sniff 100 MHz quad SPI
<azonenberg_hk>
or push jtag at 66 MHz
<azonenberg_hk>
And do so to multiple devices simultaneously
<MikeFair>
azonenberg: An ESP8266 can do 160Mhz; 384Mhz if you're willing to strip off the SDK parts (meaning no WiFi)
<cr1901_modern>
I am *choosing* the Lattice 1K for my design b/c chances are I'm not gonna fill even that for my project. The disadvantage however, is I need a lot of block RAM
<azonenberg_hk>
MikeFair: 160 MHz what, though?
<azonenberg_hk>
CPU speed? IO speed?
<cr1901_modern>
So I need to attach an SRAM
<MikeFair>
Sorry CPUP speed
<azonenberg_hk>
yeah
<azonenberg_hk>
i need something that can sniff 32 pins simultaneously at 100+ MHz
<azonenberg_hk>
and buffer for an extended period of time
<azonenberg_hk>
then send to my PC
<MikeFair>
And there are techniques for 1 cycle I/O testing
<cr1901_modern>
B/c they haven't created a "block RAM, rich, routing resource poor" FPGA yet :D
<MikeFair>
ahh
<MikeFair>
Yeah, pin count
<azonenberg_hk>
I need to be able to jtag eight devices at once
<cyrozap>
MikeFair: The ESP8266 is primarily limited by its SPI read speed, since all program data is stored there.
<azonenberg_hk>
Simultaneously
<azonenberg_hk>
and saturate gigabit ethernet
<azonenberg_hk>
I don't know of any cheap arm micro that can do that
<MikeFair>
cyrozap: (1) There is the _IRAM_ATTR (sp?) to put some things into instruction RAM; and (2) Is the ESP32 with two cores going to be any better at that?
<azonenberg_hk>
you're talking cortex-A territory if you want that kind of IO bandwidth and most don't have this many peripherals
<azonenberg_hk>
I tried doing this kind of stuff with a beaglebone black
<azonenberg_hk>
it was too slow
<azonenberg_hk>
only had 100mbit ethernet (although the soc is capable of gig the board doesnt have a gig PHY) and a few channels of jtag maxed out the cpu
<azonenberg_hk>
cr1901_modern: So i know i need an FPGA, the unknown is how many gates
<azonenberg_hk>
I should be able to fit the TCP offload engine plus basic peripherals in an artix 35t, maybe 50
<azonenberg_hk>
the 100 is mostly futureproofing because i want the option of adding arbitrary additional logic down the road for an end-use application
<azonenberg_hk>
Nothing would stop me from assembling identical PCBs with a lower gate count FPGA and compiling the same firmware for that
<cr1901_modern>
Okay, that's fair. I do hope I don't reach the point where artix 15 is too small tho :D
<azonenberg_hk>
cr1901_modern: by way of reference i was able to fit two channels of TCP-socket-to-JTAG in a spartan6 lx45 with some room to spare, i dont recall how full it was
<MikeFair>
At >$100 it seems very "special purpose" though
<azonenberg_hk>
And i recently got some ideas for making far more efficient use of fpga resources in the TCP stack
<azonenberg_hk>
so i should be able to have 128+ sockets in about the same gate count
<azonenberg_hk>
MikeFair: I do embedded systems RE and security testing for a living
<azonenberg_hk>
I often find myself fighting with two dozen different dongles and programmers with slightly different feature sets and io voltages
<azonenberg_hk>
i've lost count of how much time i've lost looking for a 1.8V usb-uart and only finding 3.3 or 5V ones
<rqou>
hmm I was also working on a logic analyzer
<azonenberg_hk>
Or frying a flash chip by putting it in a 3.3V dumper when the chip wanted 1.8
* MikeFair
wonders if you could possibly take all the pins and ties them to flip-flops that "look like" external RAM
<rqou>
we should maybe collaborate
<azonenberg_hk>
Being able to just have one tool that handles the whole 1.8 to 5V voltag erange
<azonenberg_hk>
in four banks with a separate vccio for each
<azonenberg_hk>
And can do basically any protocol commonly used in low to moderate speed embedded systems
<azonenberg_hk>
all with one ethernet connection you can bridg eto the LAN and share with a coworker
<azonenberg_hk>
would be super useful
<azonenberg_hk>
rqou: go for it
<cr1901_modern>
and expensive
<azonenberg_hk>
i have the LA core already written, it's currently my chipscope replacement
<azonenberg_hk>
so i'd just hook the core up to an off-chip io bus instead
<azonenberg_hk>
and make a socket interface instead of a jtag one
<azonenberg_hk>
I'm not going for ultra high speed, the comparators i have in mind will max out at around 200 Mbps
<azonenberg_hk>
But thats enough
<cr1901_modern>
I use _florent_/enjoy digital's litescope for most things
<azonenberg_hk>
we use the saleae logic at work which is nice but having to swap the la for a jtag for a uart etc constantly is annoying
<MikeFair>
azonenberg: For $10 more; put the external WiFi/433Mhz radio chips on there too
<azonenberg_hk>
especially with fragile hand-soldered connections
<azonenberg_hk>
MikeFair: if i go with the 256-pin fpga
<MikeFair>
oh, $15 and add the 900Mhz
<azonenberg_hk>
i will basically be maxing out the io pins
<azonenberg_hk>
ddr3 + gig-e + 32 channels GPIO + i2c/spi to all of the dacs, analog switches, psus, programable pullups/downs, etc
<azonenberg_hk>
oh and boot flash
<azonenberg_hk>
the chip has four ~50 pin io banks, one of which isnt fully bonded out
<rqou>
in other news I'm about to leave for a family vacation (plus 33C3 in the middle) tomorrow so I'm doing last-minute backups
<azonenberg_hk>
i need two banks for the dram, the GPIO will use almost all of one
<rqou>
and it's not working
<rqou>
thanks Windows
<azonenberg_hk>
then the ethernet will use the last one
<azonenberg_hk>
(the small one)
<rqou>
I apparently also found that my father's external HDD is dead
<azonenberg_hk>
the extra 18 pins unused in the GPIO bank will be doing all of the i2c and spi to the input stage controls
<rqou>
(I don't keep good backup practices)
<azonenberg_hk>
rqou: lol i've been burned too many times
<cr1901_modern>
rsync ftw
<azonenberg_hk>
raid1 on my and my wife's desktop
<azonenberg_hk>
raid1 on my file server that stores most of the important stuff
<rqou>
I've been lucky with 0 critical HDD failures
<azonenberg_hk>
file server and her desktop are backed up nightly via rdiffbackup to raid1 in an offsite datacenter
<rqou>
I've gotten a failure on a scratch drive that was dropped
<lain>
I once learned why you don't buy the same make/model drive all at the same time and build an array with it
<azonenberg_hk>
lain: ouch
<rqou>
and various SD card / flash drive failures
<lain>
years of flawless operation, then a drive failure. then the other drives failed in rapid succession :P
<azonenberg_hk>
i'm OK with doing that in my designs
<azonenberg_hk>
But i also have good backups and pre-emptively replace drives once they hit a certain age
<azonenberg_hk>
or show any bad sectors etc
<lain>
identical workloads over identical time -> they all failed within ~a week of each other, which was too short of a time to replace them
<MikeFair>
lain: exactly ;)
<azonenberg_hk>
And if possible i keep a spare drive of the same model handy
<azonenberg_hk>
So i can do an immediate replacement
<rqou>
also, Windows is ridiculously slow at copying
<lain>
now I use two-drive redundancy, hot spare if it's REALLY important, and a mixture of drives such that a max of two drives are the same make/model
<rqou>
and it needs babysitting
<cr1901_modern>
I backup to tape
<lain>
and I use zfs (raidz2) or windows storage spaces (ReFS on dual-parity space)
<azonenberg_hk>
lain: I've been considering adding a third drive to my main array
<lain>
:3
<azonenberg_hk>
right now its raid1 2 drives
<rqou>
otherwise it will occasionally fail with a duplicate desktop.ini error or whatever
<azonenberg_hk>
i figure if i add a third drive a year younger than the first two
<rqou>
and wait for you to click yes
<azonenberg_hk>
i should have a good level of safety
<lain>
azonenberg_hk: yeah
<MikeFair>
Though TBH; the flash hybrid drives; or just using a flash drive for a working set cache, dramatically changes the workload hitting spinning disks
<MikeFair>
(for typical use cases)
<azonenberg_hk>
rqou: anyway does my device sound like something you'd be interested in?
<rqou>
the LA?
<azonenberg_hk>
LA and then some, lol
<rqou>
it's almost exactly what I was working on
<rqou>
:P
<azonenberg_hk>
its basically going to be a 200+ MSa/s LA plus a bus pirate with 32 channels of IO up to ~150 MHz
<rqou>
except I want to be a bit more aggressive with specs
<azonenberg_hk>
and the ability to run multiple i2c, spi, jtag, uart, etc interfaces simultaneously on different pins
<azonenberg_hk>
More aggressive?
<rqou>
500Msamples/s
<azonenberg_hk>
i wanted full 5V operation on the IOs which is hard to do fast
<MikeFair>
lain: I liken it to adding more L2 cache to a CPU dramatically changing the amount of main RAM that gets used (and consequently dramatically improves spped)
<azonenberg_hk>
my LA can go that fast
<lain>
MikeFair: aye
<rqou>
but mine isn't fully thought out yet
<azonenberg_hk>
the analog input stage is my limiting factor right now
<azonenberg_hk>
my goal is full operation at 5V, survival to indefinite exposure of 12V
<lain>
my big arrays are mostly bulk storage / media archival so I haven't bothered with hybrid drives or l2arc or etc
<rqou>
I'm currently yak shaving instead
<azonenberg_hk>
brief exposure of 25V and ESD to 25+ kV human body model
<rqou>
:P
<azonenberg_hk>
Depending on the exact FPGA density i end up loading on each board you're looking at $50-100 for the FPGA
<azonenberg_hk>
about $10 for the ethernet subsystem, maybe $10 in power components
<azonenberg_hk>
$10-20 for the RAM and support stuff
<azonenberg_hk>
PCB cost is unknown but i hope to keep it to 4-layer generic design rules
<cr1901_modern>
That being said, 5V CMOS is still a thing, and IME it's a lot of trouble to interface to it b/c voltage clamps are insufficient
<azonenberg_hk>
complementary single ended outputs so i should be able to just use one of the two outputs
<azonenberg_hk>
and sorry 3.5 ns propagation delay
<azonenberg_hk>
So that's 285 MHz
<azonenberg_hk>
So you could probably sample at 500 MSa/s with it, but you wouldn't be able to get a data rate above 285 Mbps
<azonenberg_hk>
even if you were sampling on an externally provided clock from the DUT
<azonenberg_hk>
rqou: is that fast enough for you?
<MikeFair>
azonenberg: right, but what if you did something like the guys who captured images of a moving photon (aka they filmed a single photon moving through a coke bottle); which is basically like the "bullet speed" filming in the matrix; you set up several "readers" in a row; then fire them off in a chain -- to get 1000Mhz you need 10, running at 100Mhz each, triggering 1 nanasecond after each other
<azonenberg_hk>
MikeFair: You can do all kinds of tricks like that
<azonenberg_hk>
But that means more io pins
<azonenberg_hk>
i did something like that in my TDR to get 1.25 Gsa/s with like 12 bit precision
<azonenberg_hk>
using a comparator and cheap dac
<cr1901_modern>
azonenberg_hk: This isn't their intended use, but 74ACT series should have faster prop delay to convert down to 3.3V
<azonenberg_hk>
rqou: it's also $4.467 in qty 10 so a 32-bit input stage would cost $142.94
<azonenberg_hk>
just for the comparators
<cr1901_modern>
If you can live with handling 5V logic "specially"
<azonenberg_hk>
cr1901_modern: I need adjustable threshold from ~1.5 to 5V, fully variable
<cr1901_modern>
Like I said, 5V logic is special ;)
<azonenberg_hk>
The comparators will do the job
<azonenberg_hk>
It's just not going to be cheap
<MikeFair>
azonenberg: In this case, it'd all be the same I/O pin externally, just internally they'd all be connected to it, and somehow to each other to fire the 1 ns "pulse" to its negihbor
<azonenberg_hk>
MikeFair: i meant on the fpga side
<azonenberg_hk>
you need more pins
<azonenberg_hk>
i'm trying to squeeze this into a 256-pin chip which is not going to be easy
<azonenberg_hk>
a lot of oscilloscopes do exactly this with several cheap adcs interleaved
<azonenberg_hk>
but they have lots of pins to spare
<azonenberg_hk>
i'm trying hard to fit this into a 4-layer board
<azonenberg_hk>
worst case i can probably bump it from a 256 to 484 pin package and just only use the outer few rings of pins
Guest28719 has quit [Ping timeout: 260 seconds]
<MikeFair>
I've been kind of wondering about something related to this; if you used a voltage divider, I think you'd lose some precision in measuring the precise 5v scaled value; but would it still work as fast?
<MikeFair>
I mean; let's say you scaled the 5v -
<azonenberg_hk>
MikeFair: If you used relatively small resistors it would be decently fast
<MikeFair>
> 1V
<azonenberg_hk>
But the problem is, this also shrinks a 1.8V signal to 0.9V
<azonenberg_hk>
the difficulty isnt 5V, it's doing the whole range from like 1.5 to 5
<azonenberg_hk>
all at once, when you don't know what voltage you'll be encountering until you plug the board in
<MikeFair>
azonenberg: Not if your logic says "route through the proper resistor at this voltage level"
<azonenberg_hk>
That means lots of external analog switching and such
<MikeFair>
azonenberg: You'd scale all input to say 1.8V levels
<azonenberg_hk>
and in the end you still need a comparator if you want arbitrary thresholding
<azonenberg_hk>
Might as well just get a 5V tolerant comparator
<MikeFair>
azonenberg: ok, I was actually thinking about this from this reverse perspective where I have an MCU that can only supply 3.3V or 5V, but I want to talk to devices that operate higher/lower voltages
<azonenberg_hk>
Yeah
<MikeFair>
azonenberg: So it wasn't the same case as sampling
<azonenberg_hk>
Doing it at high speeds is also hard b/c a voltage divider reduces current
<azonenberg_hk>
Which reduces swing speed
<MikeFair>
azonenberg: "reduces" as in "makes better/easier for sampling because the swing distance is smaller" or "reduces" as in "gets in the way and makes it 'slower'/'take longer'"
<azonenberg_hk>
MikeFair: the latter
<azonenberg_hk>
same capacitance, lower drive current = slower slew
<MikeFair>
And does a "buck converter" differ?
<azonenberg_hk>
That's a switching power supply
<azonenberg_hk>
useless for data
<MikeFair>
not that i'm suggesting it; I've just been looking at taking 12-24V and stepping it down to 5V so these are the things I'm finding
<azonenberg_hk>
its not a level shifter, its a voltage regulator
<MikeFair>
Ahh, that makes sense
<azonenberg_hk>
rqou: also it looks like if you were ok with a slight increase in cost you could switch to the 484-ball chip
<azonenberg_hk>
that would give you transceivers so you'd have the option of hooking up some kind of high speed serial interface
<azonenberg_hk>
you wouldnt be able to use all the gpios in 4 layers
<azonenberg_hk>
but i think it'd still be more than the 256 pin chip
<azonenberg_hk>
Doing this *properly* might need 6 layers and i hope to avoid that
<azonenberg_hk>
As in, it'd be easy to do in 6 but maybe possible in 4 if you squeeze
<MikeFair>
So, in my original case, I just knew that the voltage level the MCU was providing != the voltage level of each "port"; and since I wanted it to be configurable (e.g. I expected to provide a reference voltage, or "configure" the voltage level using a register setting to route through a step-up or step-down circuit first); I was thinking about how that might/could be done
<azonenberg_hk>
Yeah something like that can be done fine at low speed
<azonenberg_hk>
problem with test equipment is it has to be fast and deal with unknown hardware
<azonenberg_hk>
and not die if you misconfigure it
<MikeFair>
azonenberg: Well the fact you think you can "autodetect" the power/voltage requirements is awesome
<azonenberg_hk>
MikeFair: my plan is to disable all output drivers by default
<MikeFair>
azonenberg: I worked with a chip that "mostly worked" when it was underpowered -- it wasn't until later when it started rebooting that I realized it wasn't getting all the power it required
<azonenberg_hk>
Input stage is 5V tolerant no matter what
<rqou>
f***ing Windows is so slow at copying files
<rqou>
that's like one of the most basic OS features
<azonenberg_hk>
then you will either say "I know what i'm doing, go generate X volts on the output rail"
<azonenberg_hk>
Or hook up a reference voltage from the PCB and say "IO runs at this level"
<azonenberg_hk>
then you can either pick a point in between ground and that reference/generated voltage automaticlaly as the threshold
<azonenberg_hk>
or specify manually
<MikeFair>
rqou: I actually find Windows is pretty good at copying files if you're not actually watching it copy at the same time (aka you don't turn on details and the copy window is hidden)
<MikeFair>
rqou: Or use the command line
<azonenberg_hk>
MikeFair: so the status window slows it down?
<rqou>
what about complaining about desktop.ini and getting stuck?
<MikeFair>
azonenberg: Yeah, GUI percentage updates seem to be in the middle of the copy loop
<rqou>
btrfs send has no stupid problems like that
<rqou>
it also can't magically have two desktop.ini files that both are and are not in the same folder simultaneously
<MikeFair>
rqou: There's often a checkbox for "answer these all the same"; otherwise use the command line; btrfs will likely just skip the file without asking
<rqou>
Linux in general just can't have magic like desktop.ini
<MikeFair>
rqou: It's considered a "System File" which is why it gets treated differently
<MikeFair>
rqou: It does; they're just all prefixed with .
<rqou>
that still isn't magic
<rqou>
windows actually makes them appear to be in the same folder
<rqou>
Linux doesn't do that
<rqou>
although it does allow you to mask directories by mounting over them
<MikeFair>
rqou: but they are in the same folder.... the equivalent to desktop.ini would be .desktop.ini
<MikeFair>
rqou: if you turn on "show system files" in the explorer shell, it's right there
<rqou>
um, windows can somehow pull in the "All Users" version and make it appear next to your version
<rqou>
afaik this is why windows needs to "discover" files before it can copy them
<rqou>
(I'm doing this through Explorer, maybe I shouldn't do that)
<MikeFair>
rqou: it discovers file by going through the path and making a file copy list (which I think speeds things up and makes it easier to deal with the copy in an async way because it shoves the whole list a separate thread)
<MikeFair>
rqou: It also gives you precalc'd size estimates and checks to see if the copy will fit on the desitnation
<rqou>
you know what speeds things up more? CoW filesystems like btrfs/zfs
<MikeFair>
rqou: How? I think you mean symlinks
<rqou>
nothing to do with symlinks
<MikeFair>
rqou: If you're making new bits on a different drive/area; CoW can't help
<rqou>
both btrfs and zfs can essentially dump all their inodes to the destination linearly
<rqou>
this doesn't strictly require CoW
<rqou>
but CoW makes doing it incrementally much faster
<MikeFair>
rqou: Maybe you're thinking incremental backups; those help a lot
Guest28719 has joined ##openfpga
<MikeFair>
rqou: ZFS calls them snapshots; not clear what BTRFS calls them
<rqou>
also snapshots
<MikeFair>
Anyway; fwiw, I've actually found Windows is really good at I/O when the GUI isn't in them way; typically can transfer at near maximum speeds
<rqou>
however, most older filesystem data structures might not easily be adapted to the "dump inode" send/receive mechanism
<MikeFair>
NTFS, as a journaled FS, is pretty good in my personal opinion; newer version support soft/hard links even if they aren't exposed through explorer
<MikeFair>
It even supports mount points
<rqou>
it's not that amazing but at least it's better than HFS+
<rqou>
my favorite anti-feature of NTFS is that it tries and fails to treat filenames as text
<MikeFair>
azonenberg: To answer your question about "gui slows it down"; yes, especially if you watch the details of the files it's copying because the GUI updates, at least in my experience, are in the middle of the file copy loop (so it can tell you what it just did)
<rqou>
imo either you succeed or you don't try
<rqou>
option 1 is like UNIX (filenames are bytes)
<rqou>
*option 2
<rqou>
option 1 doesn't currently exist
<MikeFair>
azonenberg: It's the equivalent of verbose file copy, or "verbose compiling", writing details to the terminal screen in a command line -- it's not typically "noticeable" until there's just a lot of it
<rqou>
the worst possible choice is to make filenames 16-bit units with a per-volume case folding lookup table
<rqou>
*second worst
<rqou>
the worst option is to make filenames 16-bit units that randomly get changed and/or omitted
<MikeFair>
rqou: I actually think being case sensitive is bad for users; and case preserving but case insensitive lookups is the "best" way for users to interact with the system (which is how windows does it); but it creates a major PITA for coding
<rqou>
no that's not quite how Windows does it
<rqou>
case insensitivity is per-volume configurable
<MikeFair>
rqou: ok, by default
<rqou>
and only U+0000 to U+FFFF case fold correctly
<MikeFair>
rqou: I don't quite follow your meaning about Unicode
<MikeFair>
rqou: What do you mean by "fold correctly"?
<rqou>
NTFS has a lookup table stored on the volume that is used to do case-insensitive compared
<MikeFair>
rqou: right
<rqou>
this lookup table only has 65536 entries
<rqou>
and it's contents depend on what tool formatted the volume
<rqou>
*its
<MikeFair>
with you so far
<rqou>
so if you put random bullshit in this lookup table you can cause all sorts of bugs
<rqou>
it's a failure to actually treat filenames as text
<rqou>
the abstraction is leajy
<rqou>
*leaky
<rqou>
on top of this filenames can also be non-text
<rqou>
because unpaired utf-16 surrogates are allowed
<MikeFair>
right, I guess I just don't see how that relates (1) to file copy speed, or (2) case folding (other than it could get screwed up if you use the wrong tool)
<MikeFair>
or (3) openfpga's (but I think we all know that's a given ;) )
<rqou>
your case folding table can map "a" to "B"
<rqou>
I don't know if I would call the result "case insensitive"
<rqou>
:P
<MikeFair>
rqou: Right, but I was talking about user experience; case preserving (aka when you look at the file it has the same case you gave it when it was created/last renamed) -- but lookups are case insensitive
<rqou>
doing that correctly can be fine
<rqou>
Windows is not doing it correctly
<rqou>
i have not seen a system that does do it correctly without eventually footgunning themselves
<rqou>
e.g. when Unicode changes
<MikeFair>
rqou: Actually, I'd say it's doing it properly if you want to support multiple languages; there's
<MikeFair>
The language of the filenames on the volume, are part of the volume
<MikeFair>
I guess you could rely on an external lookup table...
<rqou>
you'll end up footgunning yourself when you change your language to/from Turkish if you're not careful
<rqou>
e.g. what happens if my system is Turkish and I create i.txt and I.txt
<MikeFair>
but then you couldn't be as portable; by putting it on the volume, it makes writing tools easier and completely independent of the language support in the operating system
<rqou>
and then I change to English
<rqou>
I know that's why NTFS works the way it does
<rqou>
doesn't make it good
<MikeFair>
rqou: Design decisions suck :)
<rqou>
at least it's still better than HFS+
<MikeFair>
rqou: I think it's a choice; doesn't make it bad either
<MikeFair>
rqou: FWIW; you'll get the correct "Turkish" characters back
<rqou>
can you open both files? it seems doing it correctly requires tagging filenames with origin language
<MikeFair>
rqou: the volume is in Turkish; if you renamed the file on your English system; I think you'll lose case sensitivity if the english code character mappings didn't make it into the table
<rqou>
that's not intuitive at all
<MikeFair>
rqou: No, there's no problem opening the file; it's just a Unicode file name
<MikeFair>
oh wait
<MikeFair>
You cna't create i.txt and I.txt
<rqou>
really, try using the \\.\ trick to make a file named "nul"
<rqou>
and then come back :P
<MikeFair>
rqou: Ok, it's a 16-bit buffer interpretted as unicode
<rqou>
in Turkish I is not the upper case form of i
<rqou>
no it's not
<rqou>
unpaired surrogates are allowed
<rqou>
see, there's so many ways to footgun yourself
<rqou>
when NTFS was invented surrogate pairs didn't exist yet
<rqou>
and now they do, oops
<MikeFair>
rqou: But technically that's no longer the same Unicode; it's like ANSO vs ASCII
<MikeFair>
err ANSI
scrts has joined ##openfpga
<rqou>
personally I'd prefer the filesystem to treat filenames as bytes
<rqou>
you can wrap all the user friendly stuff on top
<rqou>
without footgunning yourself as badly
<MikeFair>
I havne't looked, but I'd expect the Turkish I and the Latin I to be different code points
<rqou>
no they're not
<rqou>
Turkish I and i overlap Latin codepoints
<rqou>
the dotted uppercase and dotless lowercase are new codepoints
<MikeFair>
rqou: Well then, like we said earlier, it depends on the data in that look up table; on that volume i.txt and I.txt will appear as different filenames
<rqou>
and you won't be able to copy them both to your English volume
<rqou>
that's dumb
<MikeFair>
rqou: I disagree; crap gets lost in translation all the time; being a case sensitive system where I type "i.txt" and it says "file does not exist" because the tool called it "I.txt" -- that's annoying ;)
<rqou>
what if you're a "dumb American" given a Turkish casing table volume?
<rqou>
you'd say that is annoying
<rqou>
to do this properly you have to tag the filenames with their language
<MikeFair>
rqou: People speaking english type english file names about as often as Turkish speaking people type Turksish file names; and both those things happen orders of magnitudes way more often than people copying to/from English <-> Turkish Volumes
<MikeFair>
rqou: Agreed; and store the case translation tables elsewhere
<rqou>
the fact that any of this logic is anywhere near the filesystem layer is imo bad design
<rqou>
windows already has a "fake a filenames" mechanism via desktop.ini
<rqou>
you can extend that to build a logical names mechanism on top of a solid filesystem that isn't full of footguns
<rqou>
although NTFS is not the worst offender
<rqou>
HFS+ applies no-longer-NFKD to filenames
<MikeFair>
Well back to FPGAs...
* MikeFair
looks for a sample to try on the edaplayground.com site. :)
<MikeFair>
azonenberg / whitequark: Would love to hear about the "PCB layout" language you were talking about
<felix_>
yeah, the input section is the tricky part of a logic analyzer. that's exactly the resaon why the device i'm working on, isn't ready yet (well apart from me being busy with other stuff; getting my masters degree was more important to me than getting the LA ready ;)
<felix_>
i might have looked at the same comparator chips; at least some similar priced ones. i decided against them, since using them would nearly triple the bom cost
<felix_>
i'm more aiming at an affordable price than creating the best technically possible device, since i want to be able to sell those afterwards ;)
<felix_>
sure, i love over-engineering stuff, but that only works out well if the customers really need the best stuff and are ok to pay for that
<MikeFair>
I think in azonenberg's case: he is own customer; and he really needs that stuff ;)
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet]
<felix_>
yep
* felix_
is more aiming at the area between the 8 euro fx2-based LAs and maybe the 700 euro saleae logic pro 16. there's not that much useful stuff available in between those...
<rqou>
Windows is finally done copying files!!!!!!!!!
<rqou>
that literally took hours
<rqou>
whereas it took about 20 min for Linux to do about the same amount of data
<MikeFair>
rqou: What bus were you using to do the copy
<rqou>
usb3
<rqou>
probably converted to SATA for the drive
<MikeFair>
rqou: With that orders of magnitude difference; something was definitely not the same in the setups
<MikeFair>
rqou: Same drive?
<rqou>
yes
<rqou>
I blame Explorer
<rqou>
Linux was done with btrfs send
<MikeFair>
USB3 supported on both computers and the external drive was connected at USB3 speed?
<MikeFair>
felix_: That's a pretty broad range! :)
<rqou>
same computer
<rqou>
same drive
<rqou>
same port
<MikeFair>
Same FS on the drive, and dual boot, not a VM right?
<rqou>
dual boot
<felix_>
btrfs. backup. /me nopes away
<rqou>
NTFS VHD with BitLocker on NTFS vs btrfs on LUKS on NTFS
Guest28719 has quit [Ping timeout: 245 seconds]
<rqou>
yeah, a little bit not the most tested :P
<rqou>
felix_ this backup only has to work at most once
<rqou>
because I'm leaving for Europe in a few hours :P
<rqou>
last minute ftw
<MikeFair>
rqou: Yeah but for that "once" doesn't it like "have to work!"
<rqou>
btrfs usually won't fail to write at all
<MikeFair>
So if its an NTFS vhd what's the actual FS on the drive?
<rqou>
it just had a tendency to confuse itself
<rqou>
drive is NTFS
<rqou>
also I have not lost any data with btrfs
<MikeFair>
Ahh, so you were backing up to an NTFS VHD file on an NTFS volume
* rqou
knocks on wood
<rqou>
yes
<felix_>
MikeFair: well, there are some chinese logic analyzers with fpga and usb2; the ones i had a look at had problems though
<rqou>
I didn't want to do it that way
<rqou>
but my father's other drive that I was originally using actually broke
<rqou>
these are all various crappy external HDDs
<rqou>
I need a better backup solution
<rqou>
I had a WD red as a backup drive but that system is currently offline
<rqou>
WD red is a prosumer drive that is hopefully better
<felix_>
smallest hp gen8 microserver costs around 190 euros, 25 euros for some more ddr3 ecc ram, 4 hdds, microsd card to boot freenas whoch uses zfs. works for me ;)
<MikeFair>
rqou: No, but at least there's something to explain that discrepency; I'm not sure a BitLocker encrypted volume inside a file (which I'm expecting wasn't a presized and defragmented file) -- and possibly on a BitLocker encrypted drive; is an optimized use case ;)
<rqou>
the drive itself has no BitLocker
<rqou>
the VHD was presized
<MikeFair>
rqou: Well that's a good thing :)
<rqou>
the non-presized LUKS in a file was faster
<MikeFair>
rqou: FWIW, for the "hours" magnitude difference I'd look at "device connected as a USB3 device" first, then "BitLocker", then "GUI explorer" :)
<rqou>
190+25 euros for 4 HDDs?
<felix_>
no, the hdd are extra
<rqou>
what size felix_?
<rqou>
oh
<rqou>
yeah that's like $400 USD by themselves
<felix_>
yep
<MikeFair>
felix_: nice
* felix_
has 2 of those systems and has also set up another one for his parents
<rqou>
4x 4TB WD Red ==> $600 USD
<felix_>
not the freshest hardware (dualcore ivy bridge celeron), but you can't beat the price if you want ecc
<rqou>
hmm yeah my old nas didn't have ecc
<rqou>
it was a Celeron j1900
<felix_>
that thing is kinda loud thoug
Guest28719 has joined ##openfpga
<felix_>
celeron j is atom-based, right?
<rqou>
I think so? mine was fanless
<MikeFair>
This makes me think of that "implement a fake Physical CD-Rom" drive idea I had; basically it's a distributed disc changer; all the disc data gets bit copied around the local LAN using something BitTorrentEsque; the in the Virtual CD mounter app you pick a Disc from the library
<rqou>
it ran off of a picopsu
<felix_>
i meant the microserver being kinda loud
<MikeFair>
(not that I'm the only one who had that, or similar, ideas)
<MikeFair>
Would work great for backups too
<rqou>
btw afaik if you want a cheap ECC RAM machine you need AMD
<felix_>
MikeFair: sounds impractical
<rqou>
apparently Intel doesn't like ECC on their low end products
<felix_>
rqou: the amd systems still supporting ecc are quite old and eat serious amounts of power. the celerons derived from core i support ecc when combined with the right pch chip
<rqou>
wait really?
<rqou>
I need to shop around again I guess
<rqou>
it was quite an endeavor getting ECC RAM for my new(ish) workstation
<rqou>
but then I'm not quite doing a normal setup there
<felix_>
yep. that's to enable the hardware vendors to ship systems with a cheap cpu option and not only a xeon e3 (which is basically an i5 or i7 without ecc fused away)
<MikeFair>
felix_: What do you mean? Which part?
<felix_>
the fake cd rom drive
<MikeFair>
felix_: Which part though? it's no different than a VHD presented through a SATA interface
<rqou>
I'm running a broadwell-ep xeon on my workstation
<felix_>
for my workstation i put a xeon e5 v3 on some asrock x99 board; supports ecc and works quite well
<rqou>
lol that's exactly what I have
<felix_>
well, a generation newer
<rqou>
except with a broadwell
<rqou>
apparently hackers on a budget think alike? :P
<rqou>
yeah, I'm running a xeon e5 v4 also on an ASRock x99
<felix_>
well, there aren;t many other options, if you want ecc and more than 4 physical cores
<MikeFair>
felix_: Or USB now that I think in terms of "external hardware"
<felix_>
MikeFair: why not use network shares or iscsi mounts? that stuff's proven ;)
<rqou>
if you read through the backlog I talk about updating the bios without first needing to update the bios
<felix_>
*proven to work
<MikeFair>
felix_: Well you can; but the use case is for hacking things that have "discs" in them (like a DVD player)
<felix_>
well, dump the original flas, chop of the first 4k of the firmware update file, extract the gbe section from the original file, put that in the new file and flash that file
<felix_>
MikeFair: ah, that way around. hm, if you have a use case for that, that can't be solved otherwise
<rqou>
flashing the file was hard
<MikeFair>
felix_: It's actually "both ways" around; the use case wasn't exclusively "upgrade my dumb DVD player to an Android driven DVD changer"
<felix_>
well, with an external programmer
<rqou>
tl;dr the chip defaults to QSPI
<rqou>
FTDI-based flashers can't do qspi
<felix_>
use an external flah programmer like a raspi or ftdi
<rqou>
you need to tell the chip to exit qspi
<felix_>
also the qspi ones start in the legacy spi mode
<rqou>
not this one
<felix_>
o_O
<rqou>
yeah
<rqou>
you can send it an exit qspi command...
<rqou>
using qspi
<MikeFair>
felix_: But yes, iSCSI is totally another option; at the time, some DVD playback wasn't working because it really wanted to check if "the disc was in the drive"
<felix_>
you remove the chip from the socket on the mainboard nad flashed it externally?
<rqou>
:P
<rqou>
yes
<rqou>
I had to bitbang the exit qspi command
<felix_>
weird
<rqou>
then used flashrom
<felix_>
iirc thats quite out of spec...
<rqou>
apparently it defaults to so-called 4-4-4 qspi mode
Bike has quit [Quit: negative interdict]
kuldeep has quit [Remote host closed the connection]
<rqou>
however you can still issue non-quad SPI reads in this mode
<rqou>
but not writes
kuldeep has joined ##openfpga
<felix_>
ok
<felix_>
never had that problem tbh
<rqou>
maybe ASRock switches between chips
<rqou>
depending on supply chain or whatever
<felix_>
possible
<rqou>
also afaik there's no hw sig check on the bios
<rqou>
which is kinda scary
<felix_>
well, basically if an attacker gets physical access to a machine, you;re doomed anyway
kuldeep_ has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
<felix_>
on haswell ulv and newer you got the bootguard thing, which might prevent that
<felix_>
but that also prevents e.g. flashing coreboot on a device with boot guard
<rqou>
did anyone ever establish if that's actually in the CPU or the PCH?
<felix_>
most vendors using bootguard don't implement stuff properly... ;P
<felix_>
the key is fused into the pch, but the verification is done by a combination of the microcode, the acm and the me
<felix_>
(acm == authenticated code module)
<felix_>
gotta get some stuff done now; bbl
kuldeep_ has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
kuldeep has quit [Ping timeout: 250 seconds]
kuldeep has joined ##openfpga
kuldeep has quit [Ping timeout: 245 seconds]
kuldeep has joined ##openfpga
azonenberg_hk has quit [Ping timeout: 260 seconds]
<pcbhdl-github>
pcbhdl/master 96a711e Andrew Zonenberg: Merge branch 'master' of github.com:pcbhdl/pcbhdl
<pcbhdl-github>
pcbhdl/master 6d16e14 Andrew Zonenberg: gitignore: added *.egg ignore rule
<pcbhdl-github>
pcbhdl/master d7d255e Andrew Zonenberg: setup: added dependency on sexpdata
<MikeFair>
Ok, so I can see there's kind of three phases to a hardware design/construction, but it's not clear to me what exactly they are/mean.... like in phase (1) I write some verilog code which describes the signal i/o, registers, clocks, and stuff and how they all interact/play together; but this a very abstract point of view; to programming I'd say this was like the "C langauge" version of the program... kind of agnostic to any speci
Guest28719 has joined ##openfpga
<MikeFair>
then in phase (2) I compile this into something that I can actually upload to an FPGA chip, this is very chip/vendor specific, but doesn't say anything about how the aactual board is laid out/composed
<felix_>
MikeFair: you message is truncated after "agnostic to any speci"
<MikeFair>
ahh, specific hardware
<MikeFair>
then in phase (3) lines are drawn onto a PCB, IC chips, resistors, capacitors, etc are placed onto the board and wired up to connect to the chip
<MikeFair>
but I feel like there's some key/core piece to the puzzle I'm just not seeing yet, like in the board layout tools there's a circuit description, and a hardware layout; but it's just not clicking for me yet what each of these views are creating/representing just yet
<MikeFair>
Anyone have a good tutorial they can point me at?
<MikeFair>
(e.g. the term "netlists" to me has this vague association to wires and components and how they are all connected, but doesn't actually describe exactly how the lines are routed around the board -- e.g. it's possible to make a netlist that can't physically be routed without crossing over an existing wire)
<MikeFair>
(but I'm not clear on whether or not that's an accurate take on the situation)
<felix_>
fpgas don't run programs. you describe the functionality you want to have and the fpga toolchain transforms that first into a netlist and that then into a configuration bitstream for the fpga
<MikeFair>
right, I'm clear on the "HDL" part; hardware description part;
<felix_>
the basic idea of the pcbhdl project is to describe the circuit on the pcb instead of drawing a schematic
<felix_>
more automation, better error checking, less annoying ;)
<azonenberg_hk>
MikeFair: a netlist is a set of components and abstract connections between them
<azonenberg_hk>
It has no physical or spatial existence
<MikeFair>
felix_: And the difference between that and something like the "breadboard view" in Fritzing is?
<azonenberg_hk>
MikeFair: the idea is to write code that compiles to a pcb netlist
<azonenberg_hk>
then you can import it into e.g. kicad and make physical layout for that circuit
<MikeFair>
azonenberg: Yeah, ok, so I am understanding that much correct; and it's not validating that it could be mapped into a physical/spatial of any particular constraint; it's just describing "plug A into port B, etc..."
<azonenberg_hk>
MikeFair: Yep
<azonenberg_hk>
So the general steps for any kind of HDL design are
<azonenberg_hk>
first, write the code
<azonenberg_hk>
second, synthesize it
<azonenberg_hk>
this is akin to compilation, it turns the human-readable source code into a netlist description
<azonenberg_hk>
third, technology mapping - this is often done as part of synthesis
<MikeFair>
And the output of a "synthesis" is a netilst then?
<azonenberg_hk>
Yes
<MikeFair>
ok
<azonenberg_hk>
techmapping produces a lower level netlist
<azonenberg_hk>
replacing abstract and/or gates etc with primitives that physically exist in the hardware of your target technology
<azonenberg_hk>
e.g. a GP_2LUT
<azonenberg_hk>
In the case of my greenpak toolchain, or icestorm, this is done by yosys
<azonenberg_hk>
as is synthesis
* MikeFair
is mentally binding that to GNU assembler==netlist; particular architecture ISA==techmapping... both of which happen during "compilation"
<azonenberg_hk>
MikeFair: it's more like, synthesis compiles to LLVM IR
<azonenberg_hk>
and techmapping is turning that into x86 or arm opcodes
<MikeFair>
yeah, that's a better mapping
<azonenberg_hk>
the first synthesis result is technology independent
<MikeFair>
exactly
<azonenberg_hk>
then the techmapped netlist is technology dependent but not device dependent necessarily
<azonenberg_hk>
for example a techmapped circuit description might be valid on any greenpak4 device
<azonenberg_hk>
(although it might not necessarily *fit* in any particular one)
<azonenberg_hk>
Then the next step is placement
* MikeFair
nods.
<azonenberg_hk>
you take the individual gates/primitives in the techmapped netlist and assign them to either x/y positions (for ASIC) or primitive sites (for FPGA)
<azonenberg_hk>
The placer normally tries to optimize the placement according to some rules... for example avoid placements that require connections which physically don't exist in the device
<MikeFair>
And I'd assume it makes some attempt to minimize... yeah ok
<azonenberg_hk>
in the case of greenpak, my placer attempts to minimize crossings between the two device halves (if you're on a slg4662x device, which has two groups of logic blocks around a center spine that has fairly limited routing resources)
<MikeFair>
That makes sense too; but it's at this point that the circuit/logic actually starts to take on some kind of form
<azonenberg_hk>
jumping the spine both uses one of the ten connections each way that are available
<azonenberg_hk>
and adds several nanoseconds of delay
<azonenberg_hk>
So you want to do it as little as posible
* MikeFair
agrees... and nods. :)
<azonenberg_hk>
The placer also obeys constraints from the user, for example "place din[] at pins 18 and 17"
<azonenberg_hk>
and optimizes around the things it can't move
<azonenberg_hk>
Placement can fail if, for example, you ask for more luts in your netlist than the chip has
<azonenberg_hk>
or you try to constrain a signal to a nonexistent pin
<MikeFair>
Right; the equivlent would be running out of registers on the CPU ;)
<azonenberg_hk>
The output of this stage has each entity in the netlist mapped to a primitive on the device
<azonenberg_hk>
and abstract connections between them
<azonenberg_hk>
After placement is done the next step is routing
<azonenberg_hk>
where you actually wire everything up
<azonenberg_hk>
In the case of greenpak this is very simple, there's a crossbar switch
<azonenberg_hk>
so the only way routing can fail is if you asked for more than ten signals to cross between the device halves in the same direction
<azonenberg_hk>
Or if you asked for a physically impossible connection
<azonenberg_hk>
e.g. routing the output of an oscillator to the input of the ADC
<azonenberg_hk>
in an FPGA, it's far more complex because you have a 2D grid of components and it may take multiple hops for a signal to get from point A to point B
<azonenberg_hk>
greenpak is an interesting FPGA-CPLD hybrid, it has a CPLD-style routing fabric (crossbar switch) with FPGA-style logic resources (LUTs)
* MikeFair
nods.
<azonenberg_hk>
Anyway, the output of the routing stage is now a fully physical circuit description that describes everything you need to know to program the chip
<azonenberg_hk>
But you cant actually load a circuit into the chip
<azonenberg_hk>
The final step is to turn the circuit description into a sequence of binary data that configures each block of the chip to implement the circuit
<MikeFair>
So if a "netlist" is the output of a "synthesis"; what's the ouput of a "placer" called?
<azonenberg_hk>
xilinx calls it a .ncd file "native circuit description"
<MikeFair>
(or does it only exist for a small intermediate length of time so it's not really a thing we typically deal with)
<azonenberg_hk>
Some folks call it a "placed netlist"
<azonenberg_hk>
or "layout" (this term is more applicable to PCBs or ASICs as those have physical form)
<azonenberg_hk>
anyway, bitstream generation involves basically looping through all of the primitives in the chip, whether used in your netlist or not
<azonenberg_hk>
and outputting some bits that tell it how to behave
<azonenberg_hk>
For example in the case of the SLG46620V, bit 689 specifies that storage element #3 should be a D flipflop if 0 and a level-triggered latch if 1
* MikeFair
nods.
<azonenberg_hk>
Bit 690 says the output of storage element #3 should be non-inverted if 0 and inverted if 1
<azonenberg_hk>
bit 691 is the reset state
<azonenberg_hk>
etc
<azonenberg_hk>
The output of this file is normally called a "bitstream" for obvious reasons
<azonenberg_hk>
of this process*
<MikeFair>
right, yeah, that part I totally get
<azonenberg_hk>
For the normal PCB design flow, you draw a schematic (analogous to coding, synthesis, and techmapping all in one)
<azonenberg_hk>
then export that to a layout tool
<MikeFair>
(not that I'd code it, but that the bitstream provides the configuration instructions for the FPGA/CPLD; and how a partial live reconfiguration by provide a second/overlay bitstream could work)
<azonenberg_hk>
and place and route mostly by hand, with some automation depending on the tool
<azonenberg_hk>
then rather than generating a bitstream you export graphic files to the PCB manufacturer
<azonenberg_hk>
Our planned HDL-based flow will involve using some kind of programming language, python in the case of our current prototype
<azonenberg_hk>
to describe the pcb netlist
<azonenberg_hk>
creating an object for each chip and making connections between them
<MikeFair>
Oh, and maybe this is the part that I'm getting hung up on; there's really no equivalent to the Verilog stage in the standard PCB workflow
<azonenberg_hk>
Then when executed it generates a netlist you can import into the standard layout process
<azonenberg_hk>
the advantage of this is that you can programmatically calculate component values
<azonenberg_hk>
have prebuilt libraries of configurable circuits that you can drop down in a design and parameterize for e.g. SMPS output voltage
<azonenberg_hk>
have loops to generate arrays of identical circuits (like multiple channels of an oscilloscope etc)
<MikeFair>
If I'm been interpretting correctly, "GERBER" is a common graphical layout file type/structure? maybe has some component descriptions/part #s built in?
<azonenberg_hk>
gerber is an extremely low level file format
<azonenberg_hk>
it basically is an array of rectangles defined by center and width/height
<azonenberg_hk>
there is no circuit information whatsoever in it
<azonenberg_hk>
it's essentially the raw data you would send to a certain type of machine that was used to make the photomasks for PCBs many years ago
<azonenberg_hk>
each rectangle is called a "flash" and the sizes are called "apertures"
<azonenberg_hk>
because it literally set up a rectnagular aperture and flashed a light onto the film
<azonenberg_hk>
Modern pcb fabs dont use gerber internally, usually some proprietary format
<MikeFair>
And these areas represented the negative space of the traces right?
<azonenberg_hk>
but the file format is so widespread that every cad package can generate it and every pfb can read it
<azonenberg_hk>
every fab*
<azonenberg_hk>
So people use it for interchange even though the original use is obsolete
<azonenberg_hk>
For copper layers each flash defines some region of metal you want to keep
<azonenberg_hk>
for soldermask layers it defines an opening you want in the mask
<MikeFair>
oh, ok, I had it backwards
<azonenberg_hk>
This is due to the fact that soldermask starts out solid, and becomes soluble in the developer when exposed
<azonenberg_hk>
whereas most of the photoresist used for etching copper is the opposite
<azonenberg_hk>
it hardens when exposed
<azonenberg_hk>
That said, any pcb fab may use a different type of resist that does it the other way around
<azonenberg_hk>
and they'll just invert the mask when they make it
* MikeFair
nods.
<azonenberg_hk>
Anyway we have some pretty advanced ideas for our pcb hdl, hopeflly some actually work
<azonenberg_hk>
for example each signal will be aware of the nominal operating voltages
<azonenberg_hk>
So it will error if you have a signal that can be up to 5V being fed to an input pin that can only tolerate 3.6V
<zino>
Sounds great.
<azonenberg_hk>
the other one that will be really cool if we can get it to work
<MikeFair>
ok so I didn't have it backwards exactly, I just must have been absorbing a section describing the soldermask stage; so the take away is, "rectangles could be defining something either way and you just need to know based on what you're doing/who is receiving it, which way it's going to go?"
<azonenberg_hk>
Yeah
<azonenberg_hk>
The general convention is copper layers are positive and mask negative
<azonenberg_hk>
anyway the other idea is that you won't actually make connections per se in pcbhdl
<azonenberg_hk>
because most of the time you dont necessarily care about them
<azonenberg_hk>
in other words, you often have a large number of indistinguishable pins
<azonenberg_hk>
which are grouped into resources
<azonenberg_hk>
like, a mcu has 32 GPIO pins
<azonenberg_hk>
of which there are four i2c ports, two spi ports, etc
<azonenberg_hk>
So we want to be able to say "this is a SPI bus" and connect to the MCU
<azonenberg_hk>
and then the build process will kinda do its own little place-and-route step to assign physical pin locations based on your constraints
<azonenberg_hk>
And error if, for example, you try to feed a clock signal to a non-clock input pin
<azonenberg_hk>
or if you try to connect five i2c buses to a chip that only has four i2c ports
<azonenberg_hk>
And this assignment will be dynamically adjustable
<azonenberg_hk>
if you decide during layout that it picked a pin that wasn't convenient to use
<azonenberg_hk>
you can just make a constraint saying "go hook up to this pin"
<azonenberg_hk>
and recompile
* MikeFair
nods.
<azonenberg_hk>
and it'll try to move things around and complain if the result cant satisfy the constraints
<azonenberg_hk>
as far as we know this has never been done before
<azonenberg_hk>
So we dont know if it will work :p
<azonenberg_hk>
The plan is to make it so all routed pins are relatively static
<azonenberg_hk>
and un-routed signals it's free to move around during a recompile
<azonenberg_hk>
So it'll have to integrate with the layout tool so it knows what's safe to move
<MikeFair>
azonenberg: I'm sure you're keeping this in mind, but I've actually rarely used the hardware SPI/I2C ports on the MCU code I've been writing; it's all bin bit-banged by the processor
<zino>
I'd like that a lot. Much more comfortable working with restraints.
<azonenberg_hk>
MikeFair: there will be some kind of type casting systme
<azonenberg_hk>
that lets you e.g. cast two GPIOPin's to an I2CPort
<azonenberg_hk>
But its too early in the design process to say how it will work
<azonenberg_hk>
its still more of a concept than an implementation
<azonenberg_hk>
zino: yeah
<azonenberg_hk>
and i want to make ip cores for things like a usb-uart
* MikeFair
nods.
<azonenberg_hk>
or a ltc3374 based smps
<azonenberg_hk>
and parameterize them to pick component values based on your application
<azonenberg_hk>
like, you say "give me 1.0V at 3A, 1.2V at 4A, and 3.3V at 1A"
<azonenberg_hk>
and you get a BOM and PCB netlist
<azonenberg_hk>
Or an error if, say, you had asked for 3.3V at 2A
<azonenberg_hk>
because the LTC3374 has eight 1A channels and that would add up to 9A output current
<zino>
I should say constraints, not restraints. English being my second language shows up today. :)
<azonenberg_hk>
zino: yeah
<azonenberg_hk>
one part is we have to make it easy to use for things like just a discrete resistor and led
<azonenberg_hk>
you shouldnt have to set up complex rules for that
<azonenberg_hk>
it has to just work
<azonenberg_hk>
we're still working on writing the back end data structures so it will be a while
<azonenberg_hk>
MikeFair: but we do want some kind of type system
<azonenberg_hk>
so that you can't accidentally hook up an i2c controller where one pin is sda and the other is scl from the wrong channel
<azonenberg_hk>
or something like that
<MikeFair>
azonenberg: The other thing I've been envisioning; and I'm not quite sure how this relates, of is some kind of simple "serial GPIO xmitter" protocol... MCU clocks are kind of slow relative to FPGA logic... so it seems like it might be feasible to take multiple boards and put SPI lines between them, then use ultrafast serial copy to duplicate the line data on another chip
<azonenberg_hk>
Totally doable, with an FPGA you might use something based on LVDS instead of just raw SPI
<azonenberg_hk>
If you look at how some ASIC emulation platforms work they actually do that
<zino>
"Just having them work" as in requiring all components to contain ideal voltage drops or treating most discrete things as 0ohm resistors?
<MikeFair>
So rather than have 16 parallel lines moving acroos the entire board, just a couple lines between a couple chips
<azonenberg_hk>
you have a massive chunk of logic split among fpga
<azonenberg_hk>
among multiple fpgas*
<azonenberg_hk>
they take all the parallel signals and serialize them to a few pins
<azonenberg_hk>
zino: well what i meant was
<azonenberg_hk>
i dont want a complex pin constraint system
<azonenberg_hk>
just to hook an led up to a resistor
<azonenberg_hk>
direct explicit connections still have to be doable
<zino>
Yea
<azonenberg_hk>
And we're going to be modeling uncertainty too
<zino>
Neat
<azonenberg_hk>
if you use a 5% resistor in the feedback loop of a SMPS
<azonenberg_hk>
the output is going to be a range with worst case min/max values
<azonenberg_hk>
and if you have a chip where Voh/Vih depend on Vdd
<azonenberg_hk>
it will calculate that for worst case corners
<azonenberg_hk>
So that you catch all the cases where a 3.2V supplied chip feeding a 5.1V supplied input doesn't work
<zino>
If you can get that working that would be really nice.
<azonenberg_hk>
but a 3.4V supplied chip feeding a 4.9V supplied one would be fine
<azonenberg_hk>
(for 3.3 and 5V nominal and 100 mV +/- variance)
<azonenberg_hk>
Yeah
<azonenberg_hk>
It will take a lot of work but should be a massive payoff
<azonenberg_hk>
i'm trying to automate away most of the manual stuff i do during design reviews etc
<azonenberg_hk>
There will be a library of JEDEC standard io levels you can import if you dont have the actual thresholds handy
<azonenberg_hk>
e.g. on a connector driving arbitrary external logic
<MikeFair>
I know it sounds kind of lame, but if you could describe a component using JSON as the object notation (close to python dictionary) I think you'd go well to making the fabled "library of published components
<azonenberg_hk>
We have ideas along that line but no idea how far it will go
<azonenberg_hk>
one hope is to import machine-readable parameters of say capacitors
<azonenberg_hk>
So you can automatically calculate C/V derating of decoupling caps
<zino>
Really cool.
<azonenberg_hk>
Since the supply voltage is known and at least a few cap vendors have machine-readable C/V curves published
<azonenberg_hk>
you can pick a cap that is, say, at least 0.3 uF at Vdd
<azonenberg_hk>
and no bigger than 0603 size
<azonenberg_hk>
and the solver will choose something to satisfy those constraints and minimize cost
<azonenberg_hk>
then give you a digikey p/n on the BOM
<MikeFair>
azonenberg: What you're descirbing reminds of Matlab's Simulink product
* zino
has to go back to the his real job where his users have just filled a 5PB filesystem. *sigh*
<azonenberg_hk>
MikeFair: how so? automatically choosing passives for a pcb sounds nothing like simulink lol
<azonenberg_hk>
zino: 5 petabytes? lol
<azonenberg_hk>
Biggest storage volume i had to admin was 18T
<azonenberg_hk>
sorry 16T after raid
<azonenberg_hk>
18 1T drives in a 4U system
<zino>
Oh, I wish I only had to manage TBs. :)
<azonenberg_hk>
not much work, just replacing a drive or two every six months when one died
<MikeFair>
azonenberg: The automatic discovery of invalid combinations; e.g. you aren't doing "heat dissaption" in what you've described; but you're really close to it
<zino>
Last year I had about 3 disks die every week.
<azonenberg_hk>
MikeFair: i want to do some level of thermal stuff eventually
<MikeFair>
azonenberg: The idea that each "part" has attributes to describe its valid output ranges
<azonenberg_hk>
the more we can do the better
<azonenberg_hk>
And in particular in most of my current boards
<azonenberg_hk>
i find myself picking an arbitrary valid pin assignment
<azonenberg_hk>
then tweaking it by hand as i do layout to ease routability
<azonenberg_hk>
and having to make sure i never break rules about whats legal to hook up
<azonenberg_hk>
if i could do that automatically with a solver it would save massive amounts of time
<azonenberg_hk>
no drawing 40 lines on a schematic when you could just ask for four DDRByteGroup objects constrained to be in the same io bank as each other
<azonenberg_hk>
and have the solver make that work
<MikeFair>
exactly
<azonenberg_hk>
Then maybe as you get to layout
<azonenberg_hk>
you might decide to constrain them to not only be in the same bank
<azonenberg_hk>
but be in banks 34 or 35
<MikeFair>
azonenberg: it'd also be nice if you could have it publish things the other way to;
<azonenberg_hk>
as those are in the area you want the ram
<azonenberg_hk>
It will output a mapping of hierarchial names to refdes
<azonenberg_hk>
and pinouts
<azonenberg_hk>
each build
<MikeFair>
azonenberg: e.g. your circuit, as designed, requires X pins of Y resources; here's a list of parts that can do what you ask
<azonenberg_hk>
you'd have to specify a device family or something
<azonenberg_hk>
I plan to make for example a "xilinx artix7" generic component
<azonenberg_hk>
and have it pick, say, the smallest pin count that does what you need
<azonenberg_hk>
you can constrain by gate count and speed grade to get a full part number
<azonenberg_hk>
or maybe "microchip pic32" generic component
<MikeFair>
azonenberg: Sure, or perhaps it can just iterate through part families; I think of it as a slow optimizer/solver kind of process
<azonenberg_hk>
there's too many options
<azonenberg_hk>
it wouldnt be useful
<azonenberg_hk>
and different mcus and fpgas need differnet supply voltages etc
<azonenberg_hk>
so other parts of the design will change
<MikeFair>
optimize on price to manufacture
<azonenberg_hk>
plausible down the road
<azonenberg_hk>
but not any time soon
<MikeFair>
right, totally agreed, and might even be coded by someone else entirely, but just the concept of something to overlay "what you've asked for, and things in my database of premanufactured printable/manufacturable objects" would be a great help
<azonenberg_hk>
yeah its plausiblee
<azonenberg_hk>
but i dont want the solver to decide if i should use a pic or an avr
<azonenberg_hk>
that seems like something the engineer really has to think about
<azonenberg_hk>
too many things like preferred software tools that arent easy to express in constraints
<MikeFair>
azonenberg: Or if I select a part, it can red out constraints the design violates (and perhaps by how much)
<azonenberg_hk>
That it will do
<azonenberg_hk>
it'll fail to assign pins if you ask for resources the chip doesnt have
<MikeFair>
azonenberg: Oh well I was kind of thinking, I've got my schematic; and I bounce over the "prefab" page, select some section of logic in my code, and start clicking/filtering on things -- I'm not quite sure what I'm envisioning as the top level selectable component part of the schematic; just being able to quickly scan through what could work or "how close" a part could be to working
<MikeFair>
azonenberg: Leave a stage/step in the process for "compiler optimizations" where someone might be able to code up PIC vs AVR -- I only bring it up because I know there's some crazy smart people out there who've done some incredible things with optimizations in compilers
<MikeFair>
azonenberg: Things I wouldn't have expected it to figure out
<MikeFair>
azonenberg: But because there are some higher level "programming patterns" that are so common, it seems the optimizers are begining see a higher level of "what I meant to accomplish" versus "what I said to do"
<MikeFair>
azonenberg: So instead of using that $5 PIC I selected 8 years ago for this component, it can swap it out for an AVR complete with the code that implements "what I meant to accomplish"
* MikeFair
shrugs.
<MikeFair>
Like I said, not something I expect you to work on/implement, but something that I thing people would be willing to work on if there's an easy stage to slide their analysis in
<MikeFair>
I guess it's just a matter of using a pipeline which you're likely to already do; they can then just add their thing as a link in the chain; just like everything else that's already there
pie__ has quit [Quit: Leaving]
X-Scale has joined ##openfpga
Bike has joined ##openfpga
m_w has joined ##openfpga
woddy has joined ##openfpga
woddy has left ##openfpga [##openfpga]
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale has joined ##openfpga
<pointfree>
cyrozap: So the outer two UDB rows use DSI for routing. The inner two UDB rows use routing fabric controlled by ROUTE registers. You can think of the DSI's and outer UDB rows as forming 4 rows of (routing) pairs in addition to the already known UDB pairs.
<pointfree>
ROUTE_PLD*IN* (PI) registers start at byte offset 0xC0. DSIINP (PI) registers also start at 0xC0. When simplifying gelFORTH, I was thinking, maybe this is another way in which DSI's and UDB routing have the same structure. I'm just trying to learn things from the addressing scheme.
mifune has joined ##openfpga
mifune has quit [Ping timeout: 245 seconds]
<rqou>
offtopic: apparently flying from ITH to EWR is really really hard
<rqou>
my sister is finally here after 5 hours of delay
Guest28719 has quit [Read error: Connection reset by peer]
Ardeshir has joined ##openfpga
Ardeshir has quit [Remote host closed the connection]
<rqou>
btw can anyone in the UK recommend me a prepaid SIM?
azonenberg_hk has quit [Ping timeout: 260 seconds]