<rqou>
WOOT: the vhdl compiler can now analyze empty entities!
<jn__>
yay
<rqou>
aka "entity <id> is begin end;" :P
<rqou>
not very useful obviously
<azonenberg>
rqou: is this going to be yosys-backed in the end?
<azonenberg>
And do you plan to add a write_vhdl command to be orthogonal to the write_verilog one?
<rqou>
this will eventually be yosys-backed, yes
<rqou>
no idea about write_vhdl though
<rqou>
currently it's not architected to be able to do that easily
<azonenberg>
i meant from yosys
<azonenberg>
as in exporting a cell-level netlist to vhdl
<azonenberg>
that would be a good way to do end-to-end testing of your flow to make sure you're getting what you expect
<rqou>
it seems like anybody can just go do that if they want?
<azonenberg>
Yeah
<azonenberg>
i just mean, if vhdl support is your baby
<azonenberg>
it'd be nice to add
<rqou>
maybe much later
<azonenberg>
i meant after you get it integrated with mainline yosys
<rqou>
maybe
<azonenberg>
way down the road
<rqou>
probably
<rqou>
anyways, the way i've implemented it right now the parser can't even be used to output a token-for-token identical file to the input
<rqou>
e.g. various optional keywords are just skipped
<rqou>
and it doesn't remember whether you had them or not
<azonenberg>
yeah thats fine
<azonenberg>
the goal of writing a hdl netlist isnt to copy the input
<azonenberg>
it's to produce something that is synthesizeable to the same parsed representation you generated from the original source
<rqou>
e.g. it doesn't tell the difference between "architecture foo of bar is begin end;" "architecture foo of bar is begin end architecture;"
<azonenberg>
So that you can either feed the AST to an external tool that only takes source code
<rqou>
some people might want that for other tools
<azonenberg>
Or debug the inner workings of some optimization pass etc
<rqou>
yeah that requires only a tiny subset of vhdl
<rqou>
hrm, opinion request: how far should line number information be propagated?
<rqou>
up to the parser output, up to the semantic analysis output, or all the way up to the elaborated output?
<rqou>
the current implementation is "only up to the parser output, and only for the 'important' stuff"
<rqou>
but this means that if you e.g. have two processes driving the same signal it probably can't tell you what lines those came from
<rqou>
azonenberg: what does yosys do?
<rqou>
(for verilog)
[X-Scale] has joined ##openfpga
<rqou>
or does yosys just not even report errors? :P
<azonenberg>
Yosys is not very good at reporting errors... they tag line number information when a signal was declared
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale
<azonenberg>
i dont think it records where the driver was
<azonenberg>
one day i want to do a big error reporting rampage on yosys
<azonenberg>
basically integrate a linting pass
<rqou>
hrm, right now my implementation could theoretically track where the driver is
<rqou>
but if i want to do this right now i need to store filenames
<rqou>
and displaying filenames is back to "very Fun(TM)"
<azonenberg>
Lol
<azonenberg>
I suggest tinkering with yosys and looking at the intermediate representation they use
<rqou>
my current plan was "i'll do that after i finish the basic analysis pass"
<azonenberg>
write some simple verilog
<azonenberg>
export to JSON
<rqou>
which is afaik mostly independent of yosys
<azonenberg>
As long as you write it in C++, yeah
<azonenberg>
Doign it in another language would require a bridge of some sort
<rqou>
i'm really tempted to write it in rust
<rqou>
but i chose c++ because c++ would be easier to integrate
<azonenberg>
Yeah
<rqou>
anyways, semantic analysis basically consists of things like "understand what kind of object each identifier is" and "understand which actual object is referred to with a given name"
<rqou>
which has to be done anyways
<rqou>
regardless of yosys ast
<rqou>
next will probably be some kind of "flatten" pass because i don't think yosys ast can handle vhdl hierarchies
<azonenberg>
yosys can handle hierarchial netlists, verilog style
<azonenberg>
I dont know how similar vhdl is
<azonenberg>
as i've only used vhdl for a few hours as an undergrad in one class
<azonenberg>
then the prof made us do schematic entry for a few labs
<azonenberg>
then i switched to verilog
<rqou>
vhdl is way more complicated
<azonenberg>
how so?
<rqou>
you can have a hierarchy of things like packages
<rqou>
which basically act like separate scopes
<rqou>
iirc verilog can have a hierarchical structure but didn't have separate namespaces?
<azonenberg>
Correct
<azonenberg>
Easy fix would just be to flatten the namespaces into the module names
<azonenberg>
so you'd have foo__bar for module bar in namespace foo
<azonenberg>
or something like that
<rqou>
yeah that's what i had in mind
<rqou>
you also probably need to elaborate some of the more complicated vhdl constructs like record types (basically a "struct") or generic types
<azonenberg>
yosys can do verilog generate statements
<azonenberg>
which aiui are similar in functionality to a generic
<azonenberg>
parameterized modules and such
<azonenberg>
records will probably have to be unpacked
<azonenberg>
you could just name the signal foo.bar or something
<rqou>
vhdl 2008 not only has that but can have an entire type be generic
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou>
e.g. something like "type my_fifo_type is array(0 to FIFO_SIZE) of FIFO_TYPE;" where both FIFO_SIZE and FIFO_TYPE are generic
<azonenberg>
i mean verilog in general doesnt have strong typing
<cyrozap>
It's surprisingly enjoyable to give constructive criticism and feedback once you get past the whole "THE GOSH DANG CORPORATIONS WANT TO PUT TERRIBLE CODE INTO OUR FREEDOM SOFTWARE REEEEEEEEEE" gut reaction.
<cyrozap>
The main thing keeping me going is that it's obvious these guys are novice FOSS contributors, and I want to leave a good first impression (and also "show them the ropes" so they can make better contributions in the future).
<cyrozap>
Everyone has to start somewhere, I guess
<rqou>
wait, cypress themselves are contributing the code?
<rqou>
not just "here's the TRM, you guys can do it"
<cyrozap>
Yup
<cyrozap>
@cypress.com emails
<rqou>
surprising coming from a Vendor :P
<rqou>
everybody else barely allows you to use their headers
<jn__>
even "here's the TRM (in public)" is more than a typical smartphone soc vendor would do :/
<rqou>
er, i can download tegra TRMs?
<rqou>
yes, QCOM is awful
<rqou>
er, maybe i can only download tegra TRMs because i registered with a .edu email
<cyrozap>
rqou: They actually started out with the PSoC 4 flash code and stuck their normal non-Free license header on it :P
<rqou>
OMAP (remember those? :P ) TRMs are available
<jn__>
OMAP! great times!
<pointfree>
It's interesting that they would want to contribute to openocd given that they already have Cypress PSoC Programmer. I think this indicates that there may be more than just openocd stuff on the way, possibly.
<jn__>
(and yes, you read my mind, i'm currently dealing with qcom hardware)
<jn__>
(but back on topic)
<rqou>
BRCM and QCOM can go and compete who is worse at publishing documentation :P
<jn__>
i'm glad bcm sold its wlan/bluetooth department to cypress
<rqou>
only part of it
<jn__>
oh, what did they keep?
<rqou>
all the "actually good" parts :P
<jn__>
ah :)
promach has quit [Quit: Leaving]
<lain>
yeah they only sold the "iot" stuff iirc?
<rqou>
hmm this reminds me
<rqou>
felix_: did you ever get around to looking at ath10k?
<cyrozap>
Looking at my openocd-devel mailing list history, it seems Cypress started working on the OpenOCD support in November of 2016 (at the latest). They even disclosed the dual-core nature of the PSoC 6 in one email :)
<rqou>
wait it's dual core?
<rqou>
damn, now i need to stop using "turn on/off interrupts" synchronization and use proper barriers :P
<cyrozap>
I couldn't find any mail from @cypress.com emails before then, so it appears that this really is their first ever direct contribution to OpenOCD.
<cyrozap>
rqou: It's M4F/M0, IIRC
<rqou>
oh
<rqou>
not SMP
<rqou>
you do still need _some_ kind of memory barriers though
<cyrozap>
No, the point of it is to be able to enter a low-power mode. I'm not sure if it'll work like big.LITTLE or if the code for the two cores is totally separate, though.
<rqou>
it can't (usefully) be big.little
<rqou>
M4F/M0 support different instruction sets
<cyrozap>
Oh, wait, it's M4/M0+
<rqou>
still
promach has joined ##openfpga
<cyrozap>
Ah, right, the M4 is a superset of the M0
<cyrozap>
And I was wrong again, it's M4F/M0+ since the M4 has an SP FPU.
dingbat has quit [Quit: Connection closed for inactivity]
<pointfree>
only the top two rows of udbs are in the PSoC 6 at the moment. Fortunately, Cypress says it has space for more.
<rqou>
hrm, i never thought about how openocd works with a dual-core chip
<rqou>
does it just open two sockets?
<cyrozap>
pointfree: It's certainly going to be interesting, since it has the M4F, USB (I assume FS), BLE, *and* the UDBs all on one chip, plus there's an M0+ thrown in, too.
<rqou>
(i know the "normal" way allows you to "skip" one of the jtag taps)
<rqou>
holy crap wow
<cyrozap>
rqou: GDB can handle multicore targets
<rqou>
even for non-SMP?
<cyrozap>
I have no idea
<rqou>
i might actually design with psoc6 now depending on price
<rqou>
my previous favorite was the stm32
<cyrozap>
The support Cypress is adding right now is just to flash the device
<rqou>
btw is there a way to flash parts with openocd without having to use gdb "monitor" commands?
<cyrozap>
Oh, and I forgot to mention it also has QSPI, which you can actually execute from
<rqou>
copying a page from the esp8266? :P
<cyrozap>
You don't *have* to execute from QSPI, but it's there if you need it
<cyrozap>
And gdb "monitor" commands just pass through to the OpenOCD TCL interface, which you can access directly by telnetting to port 4444
<cyrozap>
You normally flash without GDB
<rqou>
when i was working with an stm32 i would either flash with gdb because i needed to set up a debugging session anyways or i would flash with the rom bootloader
<cyrozap>
If the chip is supported, you just "reset init" and "program binary.elf/hex/bin/etc."
<rqou>
oh i somehow didn't know that existed
<rqou>
er wait, this is an openocd command?
<cyrozap>
Yup
<rqou>
the workflow i would use was 0) predict that you probably have a bug 1) start openocd+gdb and load elf into gdb 2) connect to target 3) use monitor to flash target 4) use monitor to reset target 5) fix bug
<rqou>
the critical step 0 meant that i would need to load up gdb anyways :P
<cyrozap>
`telnet localhost 4444` will get you into the TCL shell, then you can run those like normal TCL. Or, you can run them directly on the command line.
<rqou>
but i have to open gdb anyways
<cyrozap>
Yeah, whatever works, I guess :P
<rqou>
if i needed to flash without debugging then my boards had a jumper to force a rom boot
<rqou>
and then i would use dfu-util
<cyrozap>
Also, did I mention the M4F in the PSoC 6 runs at 150 MHz, and the M0+ at 100 MHz?
<rqou>
150mhz isn't _that_ amazing for an m4f, but 100mhz for a m0+ is nice
<cyrozap>
It's certainly a big jump from the PSoC 5LP
<cyrozap>
And it'll be _especially_ interesting to see how fast the UDBs will run :)
<pointfree>
Aren't the UDB's independent from the CPU?
<cyrozap>
Yes, but they're on the same die, so I assume they'll be able to be clocked faster than in the previous generation of PSoCs
<pointfree>
If the UDB's run faster it could make up for there being half as many at the moment. (I'd like to schedule "UDB time" like I schedule time on the CPU)
<rqou>
hard to believe it's actually been that long (10 years apparently)
<rqou>
hrm, apparently he's been released before and might just end up in jail again
amclain has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
pie__ has joined ##openfpga
<felix_>
rqou: no, i didn't really have time to dig much further into the ath10k stuff. i'm currently working on getting the office/lab i'll be sharing with 3 friends renovated and useable and i'm working on a commercial project. also had a quite bad norovirus infection from eating sushi last month; should have gone eating burgers that day instead... ;P
<rqou>
ah wow you've been busy
<felix_>
yep. oh and before the renovation of the office/lab we moved the local hackerspace to its new place, since its old place will be our new office (it's in the city center, quite affordable with four people and home-office didn't work out for me, since i'm living in a one room appartment with much stuff and unfinished projects lying around)
m_t has joined ##openfpga
<felix_>
having work and other stuff seperated and having a few people around me who are also working on their projects, will (hopefully) increase my productivity...
<rqou>
so one of the reasons for me staying in berkeley was to try and get this productivity boost
<rqou>
but it turns out that when all the housemates have "real jobs" and you're funemployed this doesn't work very well
massi has quit [Remote host closed the connection]
pie__ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
digshadow has joined ##openfpga
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
m_t has quit [Quit: Leaving]
GreeningGalaxy has joined ##openfpga
pie__ has quit [Ping timeout: 256 seconds]
GreeningGalaxy has quit [Ping timeout: 264 seconds]
GreeningGalaxy has joined ##openfpga
Hootch has quit [Quit: Leaving]
m_w has quit [Quit: Leaving]
pie_ has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
GreeningGalaxy has quit [Ping timeout: 256 seconds]
Zarutian has joined ##openfpga
GreeningGalaxy has joined ##openfpga
<rqou>
armchair lawyer thought: cleanly reimplementing verilog's vpi_user.h might be impossible in the United States thanks to Oracle v. Google
<rqou>
thoughts azonenberg/whitequark?
<lain>
what's the status on that, anyway?
<rqou>
my understanding is that apis are considered copyrightable, but Google's use was fair use
<rqou>
unless you meant vpi_user.h, which is under the IEEE copyright with non-free terms
<azonenberg>
rqou: what are the terms on it?
<rqou>
Icarus Verilog has a reimplementation that is under the somewhat undesirable (in this case) GPL
<azonenberg>
i never actually looked
<azonenberg>
The original i mean
<Zarutian>
rqou: why is GPL undesirable in that case?
<lain>
if GPL applies to the API, then anything implementing that API might be subject to GPL
<rqou>
it contaminated all VPI modules that include it
<lain>
vs a more permissive license like MIT/BSD/etc
<lain>
but I don't think GPL can apply to an API, even if the API is copyrightable...
<lain>
the API itself is defined in an IEEE spec afaik
<azonenberg>
yeah but what's the licensing terms on *that* api?
<lain>
orrrrr do you mean interfacing with a vpi binary
<lain>
like, a vpi-capable simulator
<azonenberg>
rqou: worst case (for me) you could make a GPL binary that bridges VPI out to another API
<azonenberg>
over e.g. sockets
<rqou>
I don't remember what the terms on the original vpi_user.h was
<azonenberg>
and use that as a free interface for other stuff
<lain>
yeah, I guess the complication is that it requires linking
<rqou>
I know the VHDL standard library has a "no modifications" provision
<rqou>
copyrightable apis are weird and impossible to reason about
<Zarutian>
and USA only kind of phenominon
<rqou>
yes
<azonenberg>
Again, worst case if we use iverilog's header
<openfpga-github>
yosys/master 71cbe98 Clifford Wolf: Remove use of <fpu_control.h> in minisat
<rqou>
wasn't there a bunch of lgpl too?
<azonenberg>
not in my tooling
<azonenberg>
i dont remember what yosys was
<azonenberg>
actualyl wait
<azonenberg>
sorry
<rqou>
my stuff tends to be 2-clause BSD for "real stuff"
<azonenberg>
My PAR was LGPL
<azonenberg>
Not 3-clause BSD
<rqou>
and 0BSD for random "not as important" stuff
<azonenberg>
The goal was to keep silego from forking it into their IDE and absorbing it
<azonenberg>
I use 3-clause BSD for pretty much everything else
<azonenberg>
forgot for a minute that i didn't here
<rqou>
what's the point of having the BSD "no promotion" clause?
<Zarutian>
pardon me for not knowing, who is silego?
<azonenberg>
Zarutian: manufacturer of the greenpak FPGAs i'm targeting with my tools
<Zarutian>
rqou: to prevent apearant but non-existant implied endorsement.
<rqou>
that just doesn't seem very useful/necessary
<azonenberg>
rqou: the idea is to keep them from advertising "we had rqou develop some of our project"
<Zarutian>
azonenberg: are they known for doing that? absorbing tools into their IDE? (why these manufacturers insist on IDEs is beyond me)
<trap15>
it prevents things you don't like from being associated with you for using it
<azonenberg>
Zarutian: well, the chip vendor has a GUI for schematic entry
<trap15>
also that
<azonenberg>
and no HDL flow at all
<Zarutian>
azonenberg: and some unspecified schematic propertary file format I guess?
<azonenberg>
its XML
<azonenberg>
no public docs on the schema etc
<azonenberg>
but it's veery low level
<azonenberg>
like, you have to explicitly draw a truth table in each lut
<azonenberg>
and you have to specify that you're placing that truth table in LUT2_5
<azonenberg>
basically manual PAR like the xc2064 had iirc
<azonenberg>
Which puts our toolchain in the position of being the only HDL flow available for the chip
<Zarutian>
no hierchial modularity at all?
<azonenberg>
And thus the risk of them trying to absorb it was significant
<azonenberg>
nope
<azonenberg>
you cant even port a design to a different chip
<azonenberg>
at all
<azonenberg>
you have to redo it from scratch
<azonenberg>
b/c the bitstream layout is different
<Zarutian>
this might explain why I have heard so little of greenpak FPGAs.
<azonenberg>
They're also tiny
<azonenberg>
like, 2x2.5 mm package, 26 LUTs or so
<azonenberg>
0.5 USD in low volume
<azonenberg>
per chip
<azonenberg>
But i figrued it was a good stepping stone to bigger things
<Zarutian>
so, it is more like a PAL, GAL or PLA than actual FPGA. Or just an LUT on a chip.
<azonenberg>
it's a mixed signal device
<azonenberg>
you have comparators, a PGA, some voltage references, etc too
<azonenberg>
then some digital hard IP like counters and PWM generators
<azonenberg>
i like to think of it as the PSoC's little brother without a CPU
<Zarutian>
IP -> design modules, no?
<azonenberg>
Yeah
<azonenberg>
there's a bunch of hard wired peripherals
* Zarutian
strictly associates IP with Internet Protocol.
<azonenberg>
Lol
<azonenberg>
now just wait until you have a network protocol accelerator for FPGA/ASIC
<azonenberg>
Now you have IP IP :D
<rqou>
we already have that :P
<azonenberg>
But yes in general the use case is more along the lines of a GAL/CPLD
<azonenberg>
but with some analog stuff mixed in too
<azonenberg>
their target market is things like PMICs, fan controllers, reset sequencing, etc
<azonenberg>
I was planning to use them for stuff like that on boards with large multi-rail FPGAs and SoCs
<Zarutian>
I see.
<azonenberg>
But you can fit quite a bit in them
<azonenberg>
i managed to fit the auto-negotiation component of 10baseT ethernet into one a while ago and it wasn't even completely full
<azonenberg>
if i really tried (and provided an external clock source) i bet i could do a full 10baseT PHY in maybe two of them
<Zarutian>
auto-negotiation component? is that the thing that detects if the cable you got and the other end is repecitly, cross-over or not and the other end is a switch or another endpoint?
<azonenberg>
I didn't do MDI-X
<azonenberg>
just negotiating 10mbit full duplex
<azonenberg>
Auto crossover might be doable with a little more work but i'd likely need two chips for that
<azonenberg>
But i havent really tried squeezing for area yet
<azonenberg>
i might be able to make it smaller
m_w has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
GreeningGalaxy has quit [Ping timeout: 246 seconds]