<lain>
I was just reading the vivado vhdl-2008 supported features
<rqou>
encrypted VHDL required algorithms: DES in CBC mode (FIPS PUB 46-3 [B4], FIPS PUB 81 [B5]).
<rqou>
that's it
<rqou>
:P
<lain>
lol
<rqou>
even 3des is optional
<lain>
do they at least mandate a random IV per file? :P
<rqou>
nope
<rqou>
"It is recommended that the initialization vector be randomly generated for each use of the cipher."
<lain>
that's worded so poorly :D
<rqou>
required digest methods: sha1, md5
<rqou>
no mention of sha256
<rqou>
although it is extensible so you can use that if the tool supports it
<rqou>
hardware engineers doing crypto, what fun :P
<lain>
XD
scrts has joined ##openfpga
<rqou>
verilog (the 2005 lrm, not systemverilog) seems to be ambiguous and doesn't say anything beyond "8-bit ASCII"
<rqou>
but that doesn't exclude utf-8
<balrog>
rqou: what's 8 bit ascii?
<balrog>
ISO 8859?
<rqou>
i assume it means "any 8-bit superset of ascii"
<balrog>
specifically ISO 8859-1?
<rqou>
verilog doesn't say that
<balrog>
lol...
<rqou>
it does have explicit bytes (matching ascii) for special characters that are part of the language
<lain>
typical verilog
<rqou>
and afaik says nothing about anything else
<lain>
"just do whatever, if the synthesizer doesn't understand it, it's free to make stuff up to fill in the gaps"
<lain>
:P
<rqou>
so you can use koi8-u or something crazy if you like :P
<rqou>
it seems to imply that verilog strings work on 8-bit units (so not codepoints)
<rqou>
but utf-8 should be ok
<rqou>
string types will just see the individual bytes
<rqou>
hell, even shift-jis / big5 might work :P
<rqou>
or wait, maybe not
<rqou>
the way i read it you aren't forbidden from using a dbcs like shift-jis/big5, but if the second byte of a character matches an ascii control character, the parser should blow up :P
<lain>
oh nice, vhdl-2008 supports case/generate, not just if/generate. and it adds much-needed support for 'else' in if/generate statements
<lain>
that was really lacking before
<rqou>
hmm the verilog 2005 lrm just conflates characters and bytes everywhere
<rqou>
most things are defined in terms of characters
<rqou>
some things like identifiers are explicitly ascii
<rqou>
' and ` are explicitly spelled out as being 0x27 and 0x60
<rqou>
so i don't know what's supposed to happen if you feed a dbcs into it
<rqou>
utf-8 seems it should work
_whitelogger has joined ##openfpga
maaku has quit [Quit: No Ping reply in 180 seconds.]
carl0s has quit [Remote host closed the connection]
<pointfree>
pie_: for RE?
<pie_>
ehh, not really, im not sure why i posted it here. i cant think of any immediate applications unless you have something statistical-like
<pie_>
well for the latter link anyway
<pie_>
like...i cant think of anything where you have data points and such to analyze, or mathematical expressions of a similar kind
<pie_>
the sensitivity analysis page isnt as itneresting as id hoped
<pointfree>
pie_: I initially have uncertainty when REing, so I use a statistical approach of sorts when I first start. e.g. There are always twice as many HV registers as VS registers, therefore the VS registers are sandwiched between two HV registers.
<pie_>
well, just because i cant think of it doesnt mean it doesnt exist :P
<pointfree>
...and it's not always true, because you can have two VS registers connecting to each other when traversing two UDB Pairs to route to the other side of the bank (such as from one row of DSI's to the other)